Задача следующая. С программой через веб-интерфейс должно работать несколько пользователей. При этом результаты работы этих пользователей должны отображаться на экране у оператора, который запустил эту программу у себя на компьютере и работает с ней через полноценный графический GUI. Как все это можно реализовать? Желательно не использовать при этом дополнительных программ (тот же самый Apache). Может посоветуете какие-то готовые библиотеки, которые позволяют организовать такой веб-интерфейс? Заранее спасибо.

• посоветуйте как реализовать...,satelit, 08:46 , 17-Янв-05
  • посоветуйте как реализовать...,rWizard, 09:32 , 17-Янв-05
    • посоветуйте как реализовать...,satelit, 09:53 , 17-Янв-05
      • посоветуйте как реализовать...,rWizard, 12:56 , 17-Янв-05
        • посоветуйте как реализовать...,chip, 19:34 , 19-Янв-05
          • посоветуйте как реализовать...,rWizard, 09:26 , 20-Янв-05
            • посоветуйте как реализовать...,chip, 09:59 , 20-Янв-05

>Задача следующая. С программой через веб-интерфейс должно работать несколько пользователей. При этом
>результаты работы этих пользователей должны отображаться на экране у оператора, который
>запустил эту программу у себя на компьютере и работает с ней
>через полноценный графический GUI. Как все это можно реализовать? Желательно не
>использовать при этом дополнительных программ (тот же самый Apache). Может посоветуете
>какие-то готовые библиотеки, которые позволяют организовать такой веб-интерфейс? Заранее спасибо.

Обрати внимание на возможности Perl'а в этой области и библиотеки LWP, при этом клиенты будут работать через любой веб броузер.

Согласен по поводу perl`а
Если всё-же использовать Apache (или другой веб-сервер), то схема может-бвть такая:
Веб (Perl как CGI) -> результаты отдаются даемону (на том-же perl-ле), а программа оперетора заберает результаты у даемона.

>Согласен по поводу perl`а
>Если всё-же использовать Apache (или другой веб-сервер), то схема может-бвть такая:
>Веб (Perl как CGI) -> результаты отдаются даемону (на том-же perl-ле), а программа оперетора заберает результаты у даемона.

Зачем городить такой огород, когда перл позволяет все реализовать без apache, хотя тогда написание скрипта немного усложнится, но для начинающих лучше все таки через apache, меньше ошибок налепят.

>Зачем городить такой огород, когда перл позволяет все реализовать без apache
например для скорости.
что будет быстрее работать -
apache + mod_perl + mod_deflate например
или
совой веб-сервер на perl`е
+ усложниться написание, соответственно увеличеться кол-во возможных ошибок.

>>Зачем городить такой огород,

полностью согласен.

>когда перл позволяет все реализовать без apache
>например для скорости.
>что будет быстрее работать -
>apache + mod_perl + mod_deflate например

Пан, не забыл еще одну компоненту ? упоминавшуюся им же самим: "результаты отдаются даемону (на том-же perl-ле), а программа оперетора заберает результаты у даемона.". Это есть чистой воды огород.

>или
>совой веб-сервер на perl`е
>+ усложниться написание, соответственно увеличеться кол-во возможных ошибок.

HTTP сервер, вроде даже включен в поставку python в качестве модуля. За сим можно сделать соотвествующий вывод - реализация оного не так уж и сложна.

Да, реализация не очень сложна. А функциональная/моштабируеемя реализация?

при увеличении нагрузки на perl-веб сервер прийдется прикручивать внешнее кеширование, захочется что-нибуть из функционала mod_rewrite и т.д.

PS а в качестве "прогладки" между CGI и Программой Оператора можно использовать и СУБД
PPS не отрицаю, что в некоторых случая предложенный вами вариант лучше

>Да, реализация не очень сложна. А функциональная/моштабируеемя реализация?

см. в сторону CUPS и localhost:631.

>при увеличении нагрузки на perl-веб сервер прийдется прикручивать внешнее кеширование, захочется что-нибуть
>из функционала mod_rewrite и т.д.
>
>PS а в качестве "прогладки" между CGI и Программой Оператора можно использовать
>и СУБД

воробьи продолжали летать и чирикать, танки продолжали наезжать и стрелять.