Вот вздумалось мне вместо perl и php попрограммировать для веба на C++. Не подскажет ли кто-нибудь хороший фреймворк для FreeBSD, ибо самому найти не удалось

Вот, удалось найти библу CGIC:

http://www.boutell.com/cgic/

Есть ли альтернативы?

Здравствуйте, Аноним, Вы писали:

А>Вот, удалось найти библу CGIC:

А>http://www.boutell.com/cgic/

А>Есть ли альтернативы?

Что за радость CGI какие-то делать. Ладно ещё FastCGI или плагин к Apach. По хорошему, вообще лучше без Web сервера, повесил демон на 80 порт, пул тредов сделал, интерпретатор HTML-шаблонов и фигачишь.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Вот, удалось найти библу CGIC:

А>>http://www.boutell.com/cgic/

А>>Есть ли альтернативы?

А>Что за радость CGI какие-то делать. Ладно ещё FastCGI или плагин к Apach. По хорошему, вообще лучше без Web сервера, повесил демон на 80 порт, пул тредов сделал, интерпретатор HTML-шаблонов и фигачишь.

Ну как-то совсем много придется самому делать Это же надо поднимать все, начиная с сокетов. Весь http протокол самому поддержать надо

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Вот, удалось найти библу CGIC:

А>>http://www.boutell.com/cgic/

А>>Есть ли альтернативы?

А>Что за радость CGI какие-то делать. Ладно ещё FastCGI или плагин к Apach. По хорошему, вообще лучше без Web сервера, повесил демон на 80 порт, пул тредов сделал, интерпретатор HTML-шаблонов и фигачишь.

Так вот вопрос топа-то и есть в том, есть ли шаблоны таких демонов???

Здравствуйте, Аноним, Вы писали:

А>>Что за радость CGI какие-то делать. Ладно ещё FastCGI или плагин к Apach. По хорошему, вообще лучше без Web сервера, повесил демон на 80 порт, пул тредов сделал, интерпретатор HTML-шаблонов и фигачишь.

А>Так вот вопрос топа-то и есть в том, есть ли шаблоны таких демонов???

Неа. Не каждый портал отходит от старой доброй традиции писать всё на банальных скриптах или жабе. А уж авторам интернет-магазинов, куда лишь изредко забредает одинокий серфер, так и вообще не до того.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>>Что за радость CGI какие-то делать. Ладно ещё FastCGI или плагин к Apach. По хорошему, вообще лучше без Web сервера, повесил демон на 80 порт, пул тредов сделал, интерпретатор HTML-шаблонов и фигачишь.

А>>Так вот вопрос топа-то и есть в том, есть ли шаблоны таких демонов???

А>Неа. Не каждый портал отходит от старой доброй традиции писать всё на банальных скриптах или жабе. А уж авторам интернет-магазинов, куда лишь изредко забредает одинокий серфер, так и вообще не до того.

Хорошо, тогда поставим вопрос так. Есть ли вобще смысл братья за это благородное дело?

Здравствуйте, Аноним, Вы писали:

А>Хорошо, тогда поставим вопрос так. Есть ли вобще смысл братья за это благородное дело?

Смотря какие цели преследовать. Чтоб делать на заказ корпрративные сайты — не имеет. Чтоб делать порталы, куда одновременно народ сотнями и тысячами может ломиться — имеет.

Здравствуйте, Аноним, Вы писали:

А>>Хорошо, тогда поставим вопрос так. Есть ли вобще смысл братья за это благородное дело?

А>Смотря какие цели преследовать. Чтоб делать на заказ корпрративные сайты — не имеет. Чтоб делать порталы, куда одновременно народ сотнями и тысячами может ломиться — имеет.

Да, речь о сотнях и тысячах) Ну может есть какте-то удобные решения для работы с http-протоколом? Придется ведь с сокетами работать...

Здравствуйте, Аноним, Вы писали:

А>Да, речь о сотнях и тысячах) Ну может есть какте-то удобные решения для работы с http-протоколом? Придется ведь с сокетами работать...

По сравнению со всем остальным поддержка http-протокола такой пустяк. Может, "curl" пригодится? Правда либа — жесть. Чистый C.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Да, речь о сотнях и тысячах) Ну может есть какте-то удобные решения для работы с http-протоколом? Придется ведь с сокетами работать...

А>По сравнению со всем остальным поддержка http-протокола такой пустяк. Может, "curl" пригодится? Правда либа — жесть. Чистый C.

Нам не привыкать))) За curl — спасибо, посмотрю.
А что тогда не пустяк? https?

Здравствуйте, <Аноним>, Вы писали:

А>Да, речь о сотнях и тысячах) Ну может есть какте-то удобные решения для работы с http-протоколом? Придется ведь с сокетами работать...

При разработке на C(++) вы огребете гемороя по полной. Я бы выбрал джаву/mod_perl. Или еще чего. Но отлаживать большое веб-приложение на C…
Оцените стоймоить разработки, оцените стоймость железа. Я почти уверен, что поставить в систему еще гиг памяти будет гораздо дешевле.

Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>Здравствуйте, <Аноним>, Вы писали:

А>>Да, речь о сотнях и тысячах) Ну может есть какте-то удобные решения для работы с http-протоколом? Придется ведь с сокетами работать...

AK>При разработке на C(++) вы огребете гемороя по полной. Я бы выбрал джаву/mod_perl. Или еще чего. Но отлаживать большое веб-приложение на C…
AK>Оцените стоймоить разработки, оцените стоймость железа. Я почти уверен, что поставить в систему еще гиг памяти будет гораздо дешевле.

Вот не надо говорить "C(++)", это два совершенно разных языка, практически не имеющие ничего общего с точки зрения идеалогии.

Я боюсь что на процедурном языке (perl/php) при росте системы код рано или поздно начнет сыпаться.

Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>mod_perl

Гы-гы-гы. А где кешировать данные из базы, сохранять текущий контекст пользователя? Тут дело не в памяти и не в процессоре, а в дибилизме архитектуры.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>>mod_perl

А>Гы-гы-гы. А где кешировать данные из базы, сохранять текущий контекст пользователя? Тут дело не в памяти и не в процессоре, а в дибилизме архитектуры.

Вот... Наверно именно это я и имел ввиду

Новая планка мозгов не сделает систему более гибкой. А сэкономив на разработке собственной системе можно в дальнейшем тратить очень много денег на саппорт развившегося "уродца".

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>>mod_perl

А>Гы-гы-гы. А где кешировать данные из базы, сохранять текущий контекст пользователя? Тут дело не в памяти и не в процессоре, а в дибилизме архитектуры.

dammit.

mod_perl

повторяю.

не perl-как-cgi.

а mod_perl.

Здравствуйте, <Аноним>, Вы писали:

А>Вот не надо говорить "C(++)", это два совершенно разных языка, практически не имеющие ничего общего с точки зрения идеалогии.

А>Я боюсь что на процедурном языке (perl/php) при росте системы код рано или поздно начнет сыпаться.

Писать можно по разному.
А веду я все к тому, что TCO для системы на С/C++ будет больше (в разы?), чем для системы на perl/java.
При сомнительных плюсах.

Здравствуйте, <Аноним>, Вы писали:

А>Новая планка мозгов не сделает систему более гибкой. А сэкономив на разработке собственной системе можно в дальнейшем тратить очень много денег на саппорт развившегося "уродца".

А это уже зависит от тех, кто эту систему дизайнит. И это не имеет почти никакого отношения к языку.

Здравствуйте, Alex Kirhenshtein, Вы писали:

А>>Гы-гы-гы. А где кешировать данные из базы, сохранять текущий контекст пользователя? Тут дело не в памяти и не в процессоре, а в дибилизме архитектуры.

AK>dammit.

AK>mod_perl

AK>повторяю.

AK>не perl-как-cgi.

AK>а mod_perl.

Не знаю чем mod_perl отличается от mod_php. Был у нас php-умелец. Так кроме как в самой базе кешировать данные из неё же места не нашёл.

Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>Здравствуйте, <Аноним>, Вы писали:

А>>Новая планка мозгов не сделает систему более гибкой. А сэкономив на разработке собственной системе можно в дальнейшем тратить очень много денег на саппорт развившегося "уродца".

AK>А это уже зависит от тех, кто эту систему дизайнит. И это не имеет почти никакого отношения к языку.

Ну попробуйте написать качественную систему на Delphi