Комментарии 6
Вы же сделали адаптер WSGI-CGI?
Для этого есть trac.saddi.com/flup, он умеет WSGI адаптировать в CGI в обе стороны.
Даже код похож trac.saddi.com/flup/browser/flup/server/cgi.py
Для этого есть trac.saddi.com/flup, он умеет WSGI адаптировать в CGI в обе стороны.
Даже код похож trac.saddi.com/flup/browser/flup/server/cgi.py
Не совсем так. CGI это протокол обмена между веб сервером и CGI приложением. Просто так CGI приложение прицепить к xinetd не получается, потому, что xinetd выдает прямо HTTP запрос, а он отличается от запроса по стандарту CGI.
Код же похож в частности потому, что в основе WSGI части в основе лежит одно и то же — пример работы по протоколу WSGI из PEP 333.
Код же похож в частности потому, что в основе WSGI части в основе лежит одно и то же — пример работы по протоколу WSGI из PEP 333.
Чёрт побери. Вот как десктопные приложения перекочёвывают в веб.
Недавно человеку надо было сделать как-то хитрый калькулятор для себя с выгрузкой данных и её хранением. Коллега убеждал его, что это нужно делать с помощью других технологий, чтобы запускалось как приложение и ему надо обратиться к другим людям. Клиент спрашивал «почему», а мы не нашлись, что ответить.
В итоге сделали всё на джанге, прикрутили аякс, чувак создал хромом ярлык приложения и доволен как слон. Необычный опыт.
Недавно человеку надо было сделать как-то хитрый калькулятор для себя с выгрузкой данных и её хранением. Коллега убеждал его, что это нужно делать с помощью других технологий, чтобы запускалось как приложение и ему надо обратиться к другим людям. Клиент спрашивал «почему», а мы не нашлись, что ответить.
В итоге сделали всё на джанге, прикрутили аякс, чувак создал хромом ярлык приложения и доволен как слон. Необычный опыт.
Я раньше скептически относился к этому, а теперь думаю, почему нет? Есть конечно минусы. Но в плюсах переносимость между, возможность сетевой прозрачности и вплоть до облачных решений.
Я о том же. Сделали. Работает. Работает хорошо. По оценкам, то же самое на PyQt обошлось бы чуть дольше, дороже и менее расширямо.
Но вот всё-таки вот не покидает ощущение, что сделали как-то через жопу, простите.
Но вот всё-таки вот не покидает ощущение, что сделали как-то через жопу, простите.
Я бы выразился помягче: «несколько непривычно». Но, с другой стороны, по похожей архитектуре (клиент-сервер) работают многие приложения. Да те же X-ы в Юниксах. В минусах мы имеем некоторую громоздкость, Хотя тоже как поглядеть, в фреймворках для локальных приложений приходится в итоге городить те же самые элементы: шаблонизаторы, базы данных и встроенные скриптовые языки. Получается то же самое, только еще осваивать другой фреймворк.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Django: запуск при помощи xinetd