Вот вздумалось мне вместо 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

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

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

С вами все понятно. Почитали бы книжки, потом бы охаивали технологии?

Почитайте success stories, потом подумайте.

О мозгах архитектора.

В качестве примера того, что можно сделать на модперле:

We have been running ModPerl to deliver dynamic applications as part of
bbc.co.uk for the past 4 years. At present we have well over 50
applications ( and growing ) using Modperl and based on the
Apache::Registry framework. These include community, message boards,
games, voting, quizzes, searches and listings applications. It serves a
sustained 500 application requests per second using a distributed
architecture.

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

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

Я не пишу на дельфи. Но на нем можно замечательно написать cgi-шку. Или под fastcgi, скажем.
Просто сажать за клавиатуры надо не макак. Или иметь хорошего архитектора.

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

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

AK>Я не пишу на дельфи. Но на нем можно замечательно написать cgi-шку. Или под fastcgi, скажем.
AK>Просто сажать за клавиатуры надо не макак. Или иметь хорошего архитектора.

Я не понимаю, Вы сейчас пытаетесь мне сказать что на процедурной идеологии можно без проблем писать огромные системы? Я думаю, даже отступая от темы web-программирования, тут никто из здравомыслящих пользователей с Вами не согласится — концепция ООП на порядок "лучше" процедурного программирования.

Так вот вопрос в том, что perl/php дешевле сначала, но дорого потом. C++ же, на мой взгляд наоборот. А что будет дешевле в итоге?

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

А>Я не понимаю, Вы сейчас пытаетесь мне сказать что на процедурной идеологии можно без проблем писать огромные системы? Я думаю, даже отступая от темы web-программирования, тут никто из здравомыслящих пользователей с Вами не согласится — концепция ООП на порядок "лучше" процедурного программирования.

zomg.

да, без ООП можно писать большие системы.

можно побольще аргументов, кроме "лучше"?

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

AAK>С вами все понятно. Почитали бы книжки, потом бы охаивали технологии?
AK>Почитайте success stories, потом подумайте.
Да чего читать. Все mod_xxx одинаковы. Тупо выполняют скрипт из файла. Соответственно скрипт не может хранить данные, доступные нескольким http-запросам одновременно.

AK>О мозгах архитектора.
Какого архитектора? Не было никакого архитектора вообще. Прикрутили скрипты к web-серверу, как могли.

AK>В качестве примера того, что можно сделать на модперле:
AK>

AK> We have been running ModPerl to deliver dynamic applications as part of
AK> bbc.co.uk for the past 4 years. At present we have well over 50
AK> applications ( and growing ) using Modperl and based on the
AK> Apache::Registry framework. These include community, message boards,
AK> games, voting, quizzes, searches and listings applications. It serves a
AK> sustained 500 application requests per second using a distributed
AK> architecture.

Ага, "distributed" на 50 серваков.

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

А>Да, речь о сотнях и тысячах)

Сходи в RSDN.decl, тебе приведут ссылку на человека, который держит сайт онлайнового казино.

Пытался сервер сделать на Java, потом пытался сделать на Haskel'e, в конце концов сумел сделать на Erlang'e

А> Все mod_xxx одинаковы. Тупо выполняют скрипт из файла. Соответственно скрипт не может хранить данные, доступные нескольким http-запросам одновременно.

Одновременно — это долго ?

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

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

CGICC

На мой взгляд удобная библиотека, поддерживает также и fastcgi.