Да, идея использовать один и тот-же шаблон на бэкенде и у клиента мне тоже очень нравится. Тут особенно хорошо тем кто на NodeJS что-то делает. Берёшь любой JS движок и вперёд.
А PURE мы не осилили. слишком уж он усложняет и без того непростую задачу по генерации
Такая идея есть, но тут есть загвоздка в том, что в Django можно делать свои теги, а в js этих тегов понятное дело не будет, да и наш парсер шаблонов о них ничего не знает. Т.е. для Django так сделать не получится.
С Jinja ситуация другая, набор тегов там фиксированный и расширяется довольно редко. Единственное что нужно это чтобы со стороны клиента environment (фильтры, глобальные объекты и т.д.) был такой-же как и на сервере, что вполне осуществимо. Архитектурно мы Jinja во многом копируем.
Идея зрела какое-то время и начинали мы как раз с того что чтобы не плодить мини-велосипеды пытались использовать парсер Jinja2, но отказались, уже не помню почему.
> вопрос: внутри контейнера тоже нужно использовать цепочку FORWARD, или там уже применяется
> INPUT/OUTPUT, как на хост-машине?
внутри почти полноценный iptables.
> если злоумышленник получит root-привилегии в контейнере, то он сможет повлиять и на firewall тоже
да, но только в рамках этого контейнера.
думаю если у него уже будет root, то то, что на фаерволе уровнем выше закрыты порты уже мало чем поможет.
Я её (релизацию) уже с месяц хочу на pypi выложить, но всё никак руки не доходят подчистить и оформить всё.
Относительно web-socket-js — мы его сильно не нагружали, по этому поводу ничего сказать не могу, но у него внутри никакого rocket science, поэтому думаю нормально всё должно быть.
согласен, но я о том, что в контексте «асинхронизации джанги» магия этого подхода в том, что его можно воткнуть в небольшом количестве мест в самом низу, почти не меняя сам фреймворк
А PURE мы не осилили. слишком уж он усложняет и без того непростую задачу по генерации
С Jinja ситуация другая, набор тегов там фиксированный и расширяется довольно редко. Единственное что нужно это чтобы со стороны клиента environment (фильтры, глобальные объекты и т.д.) был такой-же как и на сервере, что вполне осуществимо. Архитектурно мы Jinja во многом копируем.
Идея зрела какое-то время и начинали мы как раз с того что чтобы не плодить мини-велосипеды пытались использовать парсер Jinja2, но отказались, уже не помню почему.
Хотя мы в wishes.in.ua и на Django делали, могу о нём рассказать.
> INPUT/OUTPUT, как на хост-машине?
внутри почти полноценный iptables.
> если злоумышленник получит root-привилегии в контейнере, то он сможет повлиять и на firewall тоже
да, но только в рамках этого контейнера.
думаю если у него уже будет root, то то, что на фаерволе уровнем выше закрыты порты уже мало чем поможет.
Относительно web-socket-js — мы его сильно не нагружали, по этому поводу ничего сказать не могу, но у него внутри никакого rocket science, поэтому думаю нормально всё должно быть.
> Может тоже сделаете небольшую статью?
на какую тему?
в презентации есть линк на код клиента, сервера и на демо
www.slideshare.net/rushman/websockets-twisted
ну или если большой секрет, то мне в личку тоже пришлите.
чисто теоретически, оборачивая все блокирующие вызовы в tx_green.wait, можно делать их асинхронными, не меняя код который их использует.
только как минимум декоратор не inlineCallbacks всё-же назвать стоит, чтобы не путать, и предупредить что внутри магия.
а сам подход очень интересный.
bitbucket.org/rushman/tx-websockets/src/