Всем привет.

Думаю, что это будет интересно, как ответ на принципиальный вопрос о применении C++ для Web-программирования. На сайте MicroNovae лежит движок C++ server pages. Ходить сюда: http://www.micronovae.com/default_csp.html

Кстати, разработка молодая. Как я понял, началась примерно в 2002-2003 г. Вероятно, не слишком большая популярность такого решения связана с такими причинами:

Первая — долгая стабилизация стандарта C++ и подтягиванием компиляторов.
Вторая — стереотип, который напрочь разделяет понятия "C++" и "Web-программирование".
Третья — приличная масса Web-программистов, у которых в послужном списке технологий есть SQL, Java, VB и нет C++.
Четвёртая — возможность создания потенциально опасного (exploiting) кода на C++. Согласитесь, что залезть в память средствами C++ не в пример проще, чем на Java.

Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода. А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.

Вот так, или примерно так. Высказывайтесь, коллеги.

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

ГВ>Всем привет.

ГВ>Думаю, что это будет интересно, как ответ на принципиальный вопрос о применении C++ для Web-программирования. На сайте MicroNovae лежит движок C++ server pages. Ходить сюда: http://www.micronovae.com/default_csp.html

ГВ>Кстати, разработка молодая. Как я понял, началась примерно в 2002-2003 г. Вероятно, не слишком большая популярность такого решения связана с такими причинами:

ГВ>Первая — долгая стабилизация стандарта C++ и подтягиванием компиляторов.
ГВ>Вторая — стереотип, который напрочь разделяет понятия "C++" и "Web-программирование".
ГВ>Третья — приличная масса Web-программистов, у которых в послужном списке технологий есть SQL, Java, VB и нет C++.
ГВ>Четвёртая — возможность создания потенциально опасного (exploiting) кода на C++. Согласитесь, что залезть в память средствами C++ не в пример проще, чем на Java.

ГВ>Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода. А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.

ГВ>Вот так, или примерно так. Высказывайтесь, коллеги.

Не пощупав, трудно что-либо сказать.
Что касается популярности, то Web-дизайн -- слишком массовая профессия, что бы им заниматься на С++. Барьер квалификации, однако. Тут нужны более простые в освоении средства -- для чайников.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

WF>>А со стороны корпоративных пользователей? Например, путем посылки хитрого запроса.
ГВ>Хм. Хакаются, вроде как, Web-серверы (т.е. — IIS, Apache и иже с ними), а не xSP-модули, которые сами по себе серверами не являются.

Хакается все. Если на обработке query string возможно переполнение буфера внутри С++-скрипта, то это самый обыкновенный эксплоит.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А что? Их писать грамотно не нужно?
Э-э, поинт не в этом, а в том, что падать должны некорректные программы, а не все остальные вместе с ними. Устойчивость твоей программы к проходу по памяти от постороннего кода недостижима даже при бесконечно большом радиусе кривизны лично твоих рук.

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

S>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>А что? Их писать грамотно не нужно?
S>Э-э, поинт не в этом, а в том, что падать должны некорректные программы, а не все остальные вместе с ними. Устойчивость твоей программы к проходу по памяти от постороннего кода недостижима даже при бесконечно большом радиусе кривизны лично твоих рук.
Потому я и предположил, что подобная технология более удобна для сайтов, разрабатываемых одной компанией, чем для провайдеров.

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

AVK>Хакается все. Если на обработке query string возможно переполнение буфера внутри С++-скрипта, то это самый обыкновенный эксплоит.

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

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

да и не скрипт там, а компиляция чего надо куда положено

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

CS>ASP страница это byte code который цепляется как stream к файлу с расширением asp.

Сам-то понял что сказал?

ГВ>От кривизны рук всегда защититься сложно. Что поделаешь... Значит, просто требования к квалификации разработчиков должны быть выше.

Ага, с таким же успехом можно допустить, чтобы ОС падала при AV в программе и разводит руками: нужно программы грамотно писать.

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

L>Здравствуйте, c-smile, Вы писали:

CS>>ASP страница это byte code который цепляется как stream к файлу с расширением asp.

L>Сам-то понял что сказал?

Я то понял...

Про compiled здесь

Про NTFS streams здесь

Было время (когда я еще IIS интересовался) когда каждая ASP страница (как файл) хранила некий overhead.
У нас была в то время рабочая гипотеза что это оно и есть.

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

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

S>>Думается, что основная причина — это отсутствие необходимости.
S>>А нужно ли? ИМХО подавляющее большинство задач на Web решается существующими средствами и притягивать C++ просто нет необходимости, за исключением специфических задач.
ГВ>Ну мало ли что и как сейчас решается. Во всяком случае, с такой штукой можно без лишних интерфейсных наворотов (COM, CORBA etc.) сшить быстрый App-сервер и презентативную часть на базе Web. ИМХО, в некоторых случаях — просто находка.

Правильно, только в некоторых случаях. Ниша у этого продукта слишком мала.

— С ASP этому продукту тягаться бесполезно, поскольку основная прелесть ASP — это простота и интерпретация... Т.е. чтобы поправить скрипт, нужно всего-то в текстовом файле строчку перебить... А это гораздо быстрее компиляции.

— Декларируемая скорость исполнения, это хорошо, конечно, но если я (как пользователь) сижу на модеме, то мне что 63 миллисекунды, что 310 — по барабану...(взято из их тестов). Загрузка по сети определяется для меня десятками секунд.

— с точки зрения разработчика — есть ASP.NET — пишите на здоровье. Есть всё что нужно. И скорость не многим ниже.

— на сложных веб приложениях основное время, как правило, затрачивается не на непосредственную интерпретацию кода, а на использовании внешних вызываемых сервисов (например, обращение к базе данных, XSLT трансформация и т.п.)

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

В плюс ко всему сказанному можно добавить возможные проблемы с хостингом.

Но в некоторых случаях, согласен, действительно находка.

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

ГВ>Всем привет.

ГВ>Думаю, что это будет интересно, как ответ на принципиальный вопрос о применении C++ для Web-программирования. На сайте MicroNovae лежит движок C++ server pages. Ходить сюда: http://www.micronovae.com/default_csp.html

ГВ>Кстати, разработка молодая. Как я понял, началась примерно в 2002-2003 г.

А я и раньше пользовался сями для Web-сервера, когда нужда была в закрытых исходниках и быстрой обработке большого количества запросов от клиентов)

Например, копай в сторону замечательного комплекса программ UCJ (используемые языки — C и Perl).

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

V>насколько мне казалось, скриптовые языки отличаются своей интерпретируемостью. причем некоторые скриптовые языки невозможно скомпилировать.
http://en.wikipedia.org/wiki/Script_language

Scripting programming languages (commonly called scripting languages or script languages) are computer programming languages designed for "scripting" the operation of a computer. Early script languages were often called batch languages or job control languages.

Contents
1 Description

2 Notes

3 List of scripting programming languages

4 External link

Description
Computer languages are created for varying purposes and tasks — different kinds and styles of programming. One common programming task is known as scripting, or connecting diverse pre-existing components to accomplish a new related task. Those languages which are suited to scripting are typically called scripting languages. Many languages for this purpose have common properties: they favor rapid development over efficiency of execution; they are often implemented with interpreters rather than compilers; and they are strong at communication with program components written in other languages

Разницу между often и always ощущаешь?

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

ГВ>Вот так, или примерно так. Высказывайтесь, коллеги.

"Секс это что новое или мы им всегда занимались?"

В смысле идея не нова. Года три назад то ли в DDJ то ли в CUJ была большая статья на тему.

По моему (не помню) в ней описывались C++ servlets
http://stud3.tuwien.ac.at/~e9626231/cse/home.html

На самом деле это есть ни что иное как ++тизация идей CGI и пр.
Что как известно работает и вельми.

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

ГВ>Здравствуйте, c-smile, Вы писали:

CS>>На самом деле это есть ни что иное как ++тизация идей CGI и пр.
CS>>Что как известно работает и вельми.

ГВ>А эта модель не работать попросту не может. Единственная относительно серьёзная проблема — время трансляции страницы в DLL. Всё же прочее — точь в точь JSP, ASP и прочее.

время однократной трансляции

Геннадий Васильев -> "C++ server pages, однако"

ГВ> Первая — долгая стабилизация стандарта C++ и подтягиванием
ГВ> компиляторов.
ГВ> Вторая — стереотип, который напрочь разделяет понятия "C++" и
ГВ> "Web-программирование".
ГВ> Третья — приличная масса Web-программистов, у которых в послужном
ГВ> списке технологий есть SQL, Java, VB и нет C++.
ГВ> Четвёртая — возможность создания потенциально опасного (exploiting)
ГВ> кода на C++. Согласитесь, что залезть в память средствами C++ не в
ГВ> пример проще, чем на Java.

Пятая, которая косвенно проистекает из 2 и 3-й — время разработки приложения
(недостаточная квалификация, отсутствие бибилиотек и т.д.)

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Вспомним историю развития средств:
ЕК>1. CGI Хорошо, но медленно: для каждого клиента запускается отдельный процесс.

Старый офицер рассказывает курсантам:
-...Пуля, выпущенная из этого оружия, летит со скоростью 600 м/с
-Но это же медленно!
-Знаешь, я не видел, чтобы кто-нибудь бегал быстрее.

Вот другая реальность:
1. Свой веб-сервер, когда нужна действительно большая скорость.
2. Чужой веб-сервер и CGI-скрипты, dll-ки, когда скорость не нужна.

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

hrg>Рухнет поток. И все. Остальные будут работать как дальше.

А что, потоки у нас уже изолированы от общей памяти приложения?

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Использование С++ в виде dll порождает проблему 2 — падение модуля приводит к падению сервера

да ну?

вызов ф-ий DLL производится из некоей ф-ии обработчика запроса.
типа так:

void ProccessRequest(Request& rq, Response& rs) {
    try {
// тут что-то происходит со страницами
    } catch(...) {
         Responce << UNDEFINED_APPLICATION_ERROR_HTML_TEXT;
    }
}

Другое дело, что запуск в одном адресном пространствеможет что-то похерить в важных данных самого сервера...
но дык, это расплата за эффективность и прочие бенефиты.

Хотя, при желании можно прилично побороться и с такой проблемой. Например, выделить прикладным модулям свой heap в виртуальном адресном пространстве, которое с обоих сторон окружено "дырами" в виртуальной памяти. Тогда наиболее частые причины падения, типа переполнения стека и выход за границы массива будут что-то портить или в самом прикладном модуле, или натыкаться на несуществующую память и просто генерить эксепшн.

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

[SKIPPED — (мух жалко)]

S>>Но в некоторых случаях, согласен, действительно находка.
ГВ> Да, я думаю, что для программ типа ClearQuest, которые содежат собственный Web-интерфейс, самое то.
Мне первое что на ум пришло — сервер для онлайнового преферанса

Геннадий Васильев -> Re[4]: C++ server pages, однако

S>>- на сложных веб приложениях основное время, как правило,
S>>затрачивается не на непосредственную интерпретацию кода, а на
S>>использовании внешних вызываемых сервисов (например, обращение к базе
S>>данных, XSLT трансформация и т.п.)
ГВ> Ну, это как раз место для использования C++.

Уже давно все написано и подключается как библиотеки

<!-- Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно
гармонист -->

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

hrg>:) Апач не на яве написан. Если модуль запашет память (которая общая для
hrg>::всех модулей и самого апача), то рухнет всё

hrg>http://httpd.apache.org/docs/misc/API.html#pools

int* p = (int*)1;
for(int i = 0;; ++i)
    p[i] = i;

Дальше думаю объяснять не надо.

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

Ш>Не пощупав, трудно что-либо сказать.
Я сейчас скачал, буду щупать. Глядишь, библиотечку какую-никакую сваяю. За ради унификации WinAPI-контролов и HTML-представления.

Ш>Что касается популярности, то Web-дизайн -- слишком массовая профессия, что бы им заниматься на С++. Барьер квалификации, однако. Тут нужны более простые в освоении средства -- для чайников.
Ладно, повременим с ёрничаньем. В "Философии програмирования" для этого всегда время и место есть.

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

ГВ>Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода.

А со стороны корпоративных пользователей? Например, путем посылки хитрого запроса.

ГВ>А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.

На самом деле, интересно было бы посмотреть на более-менее реальное сравнение с ASP.NET/JSP. Некоторый набор стресс-тестов на более-менее реальном приложении. Мне, в общем-то, не особо понятно за счет чего CSP может сильно превзойти по скорости данные технологии.

Сравнение CSP с ASP у них на сайте — это, по-моему, издевательство какое-то. ASP же вроде интерпретируемый?

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

ГВ>>Хотя четвёртая причина должна быть более актуальна для "публичных" провайдеров, которые рискнут предоставить CSP-хостинг. Для внутрикорпоративных же сайтов угроза exploiting-кода со стороны самих C++-Web-приложений существенно меньше, поскольку такой сайт может вовсе не содержать постороннего C++-кода.
WF>А со стороны корпоративных пользователей? Например, путем посылки хитрого запроса.
Хм. Хакаются, вроде как, Web-серверы (т.е. — IIS, Apache и иже с ними), а не xSP-модули, которые сами по себе серверами не являются.

ГВ>>А скорость обработки запросов выше, однако. Сам я пока не проверял, но по идее, должно работать быстрее, чем JSP.
WF>На самом деле, интересно было бы посмотреть на более-менее реальное сравнение с ASP.NET/JSP. Некоторый набор стресс-тестов на более-менее реальном приложении. Мне, в общем-то, не особо понятно за счет чего CSP может сильно превзойти по скорости данные технологии.
Думаю, что в основном — за счёт более быстрой генерации Response-буфера.

WF>Сравнение CSP с ASP у них на сайте — это, по-моему, издевательство какое-то. ASP же вроде интерпретируемый?
Согласен, что тут они палку несколько перегнули, хотя смотрится впечатляюще. Особенно любопытно с JSP сравнить. Обязательно поковыряю на досуге.

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

WF>Сравнение CSP с ASP у них на сайте — это, по-моему, издевательство какое-то. ASP же вроде интерпретируемый?

ASP страница это byte code который цепляется как stream к файлу с расширением asp.

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

CS>На самом деле это есть ни что иное как ++тизация идей CGI и пр.
CS>Что как известно работает и вельми.

А эта модель не работать попросту не может. Единственная относительно серьёзная проблема — время трансляции страницы в DLL. Всё же прочее — точь в точь JSP, ASP и прочее.

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

V>переполнением буфера обычно страдали программы на С, где все было на статических массивах или массивах фиксированой размерности.

V>если использовать STL, то максимум что произойдет — перевыделение памяти в недрах STL, эксплоит не возможен в принципе.

Ага. Вот только почему то в сетевом софте, в том числе и писанном на плюсах, эксплойты находят регулярно.

V>да и не скрипт там, а компиляция чего надо куда положено

Скрипты тоже могут быть компилируемыми.

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

V>>если использовать STL, то максимум что произойдет — перевыделение памяти в недрах STL, эксплоит не возможен в принципе.

AVK>Ага. Вот только почему то в сетевом софте, в том числе и писанном на плюсах, эксплойты находят регулярно.

и что это за сетевой софт на плюсах, где есть эксплоит?

----------

но даже и на плюсах при достаточной кривизне рук ничто не мешает писать в духе С:

#define BIG_BUFF_LEN 1000

int some_func(stream* st) {
    ...
    char buff[BIG_BUFF_LEN]; 
    stream->read_string(buff);    // получи эксплоит
    ...
}

V>>да и не скрипт там, а компиляция чего надо куда положено

AVK>Скрипты тоже могут быть компилируемыми.

насколько мне казалось, скриптовые языки отличаются своей интерпретируемостью. причем некоторые скриптовые языки невозможно скомпилировать.

Вспомним историю развития средств:
1. CGI Хорошо, но медленно: для каждого клиента запускается отдельный процесс. Вместо этого придумали
2. ISAPI. Модули в DLL. Быстро, но глючно: AV в DLL приводит к обрушению всего web-сервера. Да и с обновлением версий модулей проблемы — требует перезапуска сервера
3. Скрипты: ASP, PHP и пр. Относительно быстро: всё в одном процессе. Надёжно: скрипт AV вызвать не может. Обновлять легко. Но когда код большой, насинаются проблемы: в коде не разобраться, да и работает не быстро, поэтому придумали 4:
4. Виртуальные машины: JSP, ASP.NET. Тут вроде пока всё хорошо. Надёжно. Довольно быстро. Код сложный можно писать. Обновлять легко.

Использование С++ в виде dll порождает проблему 2 — падение модуля приводит к падению сервера

Евгений Коробко -> "Re: C++ server pages, однако"

ЕК> Вспомним историю развития средств:
ЕК> 1. CGI Хорошо, но медленно: для каждого клиента запускается
ЕК> отдельный процесс. Вместо этого придумали
ЕК> 2. ISAPI. Модули в DLL. Быстро, но глючно: AV в DLL приводит к
ЕК> обрушению всего web-сервера. Да и с обновлением версий модулей
ЕК> проблемы — требует перезапуска сервера

2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). Быстро и
безопасно.

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Использование С++ в виде dll порождает проблему 2 — падение модуля приводит к падению сервера
От кривизны рук всегда защититься сложно. Что поделаешь... Значит, просто требования к квалификации разработчиков должны быть выше.

hrg>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). Быстро и
hrg>безопасно.

Не, это вариант 3, просто парсеры языков подключаются динамически. Кстати, бесопасны не сами модули, а языки, ими поддерживаемые. Если будет косяк в самом модуле, апач рухнет вместе с ним. И на этих модулях бизнес-логика не реализуется.

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

hrg>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp). Быстро и
hrg>безопасно.

В смысле? Если сам модуль, то он ничуть не безопаснее dll, если perl, phph, asp, то это п.3.

Евгений Коробко -> "Re[3]: C++ server pages, однако"

hrg>>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp).
hrg>>Быстро и
hrg>>безопасно.

ЕК> Не, это вариант 3, просто парсеры языков подключаются динамически.

Странная квалификация. То сначала квалифицируется по способу обработки (CGI,
DLL), то по языкам.

mod_чегототам — это полноценная библиотека *.so. В которой, в том числе
может находится и парсер конкретного языка.

ЕК> Кстати, бесопасны не сами модули, а языки, ими поддерживаемые. Если
ЕК> будет косяк в самом модуле, апач рухнет вместе с ним.

Рухнет поток. И все. Остальные будут работать как дальше. Апач просто
стартанет еще один поток. А то давно был полинтернета периодически лежало
из-за неохватного радиуса кривизны верхних хватательных конечностей
отдельных индивидов

ЕК> И на этих
ЕК> модулях бизнес-логика не реализуется.

а что же на них тогда реализуется ?

Yury Kopyl aka hrg | Гордость мешает доходам!

AndrewVK -> "Re[3]: C++ server pages, однако"

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

hrg>>2.1 Встраиваемые модули для apache (mod_perl, mod_php, mod_asp).
hrg>>Быстро и
hrg>>безопасно.

A> В смысле? Если сам модуль, то он ничуть не безопаснее dll, если perl,
A> phph, asp, то это п.3.

Модули для апача используют его интерфейс.
API Acpahe. Работаю
как хандлеры событий, которые вызывает апач. Модули могут быть написаны на
чем угодно, начиная от С, заканчивая хз чем.

Теперь к скриптовым языкам. Вызов интерпретатора скриптого языка возможет
как через механизм CGI (запускается отдельный процесс с интерпретатором) а
также его разновидноестей, FastCGI. HeavyCGI; так через обработчика хандеров
(нативный хандлер на С, mod_perl и и.д.) Причем во втором случае мы получаем
контроль практически на любом этапе обработки запроса.

[url=http://www.amazon.com/exec/obidos/tg/detail/-/156592567X/qid=1101130929
/sr=8-1/ref=pd_ka_1/104-1545509-7518306?v=glance&s=books&n=507846]Базовая
книга по написанию модулей[/url]

Yury Kopyl aka hrg | Гордость мешает доходам!

hrg>Странная квалификация. То сначала квалифицируется по способу обработки (CGI,
hrg>DLL), то по языкам.

Квалифицируется по способу реализации бизнес-логики. Создание mod_... к бизнес-логике отношения не имеет.

hrg>Рухнет поток. И все. Остальные будут работать как дальше. Апач просто
hrg>стартанет еще один поток.

Апач не на яве написан. Если модуль запашет память (которая общая для всех модулей и самого апача), то рухнет всё

hrg> а что же на них тогда реализуется ?

Расширения веб-сервера

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

V>>насколько мне казалось, скриптовые языки отличаются своей интерпретируемостью.
[...]

AVK>Разницу между often и always ощущаешь?

Разницу м/у казалось и утверждаю ощущаешь?

-----
за вырезку и ссылку +1

Евгений Коробко -> "Re[5]: C++ server pages, однако"

hrg>>Странная квалификация. То сначала квалифицируется по способу
hrg>>обработки (CGI,
hrg>>DLL), то по языкам.

ЕК> Квалифицируется по способу реализации бизнес-логики. Создание
ЕК> mod_... к бизнес-логике отношения не имеет.

(задумчиво) дай, тогда пожалуйста тове видение реализации бизнес логики по
отношению к веб-серверу.

hrg>>Рухнет поток. И все. Остальные будут работать как дальше. Апач
hrg>>просто
hrg>>стартанет еще один поток.

:) Апач не на яве написан. Если модуль запашет память (которая общая для
::всех модулей и самого апача), то рухнет всё

http://httpd.apache.org/docs/misc/API.html#pools

hrg>> а что же на них тогда реализуется ?

ЕК> Расширения веб-сервера

И какого сервера и какими расширениями, позвольте спросить?

Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон

AndrewVK -> "Re[5]: C++ server pages, однако"

hrg>>Рухнет поток. И все. Остальные будут работать как дальше.

A> А что, потоки у нас уже изолированы от общей памяти приложения?

http://httpd.apache.org/docs/misc/API.html#pools

Если писать хандлеры на mod_perl, то можно вообще забыть про эти проблемы

Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон

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

A>> А что, потоки у нас уже изолированы от общей памяти приложения?

hrg>http://httpd.apache.org/docs/misc/API.html#pools

hrg>Если писать хандлеры на mod_perl, то можно вообще забыть про эти проблемы

Это и будет п.3.

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

A>> В смысле? Если сам модуль, то он ничуть не безопаснее dll, если perl,
A>> phph, asp, то это п.3.

hrg>Модули для апача используют его интерфейс.
hrg>API Acpahe. Работаю
hrg>как хандлеры событий, которые вызывает апач. Модули могут быть написаны на
hrg>чем угодно, начиная от С, заканчивая хз чем.

"Если сам модуль, то он ничуть не безопаснее dll" (С) я

hrg>Теперь к скриптовым языкам. Вызов интерпретатора скриптого языка возможет
hrg>как через механизм CGI (запускается отдельный процесс с интерпретатором) а
hrg>также его разновидноестей, FastCGI. HeavyCGI; так через обработчика хандеров
hrg>(нативный хандлер на С, mod_perl и и.д.) Причем во втором случае мы получаем
hrg>контроль практически на любом этапе обработки запроса.

"если perl, php, asp, то это п.3." (С) я

AndrewVK -> "Re[7]: C++ server pages, однако"

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

A>>> А что, потоки у нас уже изолированы от общей памяти приложения?

hrg>>http://httpd.apache.org/docs/misc/API.html#pools

hrg>>Если писать хандлеры на mod_perl, то можно вообще забыть про эти
hrg>>проблемы

A> Это и будет п.3.

Это будет пункт 2 и 3, потому что будет возможнось управлять всем процессом
обработки запроса, тогда так п. 3 дает только возхможность обрабатывать
стадию отдачи контента

Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист

AndrewVK -> "Re[5]: C++ server pages, однако"

A> "если perl, php, asp, то это п.3." (С) я

здесь ответил

Автор: hrg
Дата: 22.11.04

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

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

A>> Это и будет п.3.

hrg>Это будет пункт 2 и 3, потому что будет возможнось управлять всем процессом

Не будет. Потому что механика модулей апача и механика скриптов конкретный модуле это две разные вещи. Никакой принцципиальной разницы между apache+mod_asp и iis+asp isapi нет.

AndrewVK -> "Re[9]: C++ server pages, однако"

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

A>>> Это и будет п.3.

hrg>>Это будет пункт 2 и 3, потому что будет возможнось управлять всем
hrg>>процессом

A> Не будет. Потому что механика модулей апача и механика скриптов
A> конкретный модуле это две разные вещи. Никакой принцципиальной
A> разницы между apache+mod_asp и iis+asp isapi нет.

будет. Как ты на asp напишешь обработку фазы аутентификации? Поэтому я
говорю — что это смесь типов 2 и 3.

Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева

Здравствуйте, Евгений Коробко, Вы писали:

ГВ>>От кривизны рук всегда защититься сложно. Что поделаешь... Значит, просто требования к квалификации разработчиков должны быть выше.
ЕК>Ага, с таким же успехом можно допустить, чтобы ОС падала при AV в программе и разводит руками: нужно программы грамотно писать.
А что? Их писать грамотно не нужно?

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

Думается, что основная причина — это отсутствие необходимости.

А нужно ли? ИМХО подавляющее большинство задач на Web решается существующими средствами и притягивать C++ просто нет необходимости, за исключением специфических задач.

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

S>Думается, что основная причина — это отсутствие необходимости.
S>А нужно ли? ИМХО подавляющее большинство задач на Web решается существующими средствами и притягивать C++ просто нет необходимости, за исключением специфических задач.
Ну мало ли что и как сейчас решается. Во всяком случае, с такой штукой можно без лишних интерфейсных наворотов (COM, CORBA etc.) сшить быстрый App-сервер и презентативную часть на базе Web. ИМХО, в некоторых случаях — просто находка.

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

S>>>Думается, что основная причина — это отсутствие необходимости.
S>>>А нужно ли? ИМХО подавляющее большинство задач на Web решается существующими средствами и притягивать C++ просто нет необходимости, за исключением специфических задач.
ГВ>>Ну мало ли что и как сейчас решается. Во всяком случае, с такой штукой можно без лишних интерфейсных наворотов (COM, CORBA etc.) сшить быстрый App-сервер и презентативную часть на базе Web. ИМХО, в некоторых случаях — просто находка.
S>Правильно, только в некоторых случаях. Ниша у этого продукта слишком мала.

S>- С ASP этому продукту тягаться бесполезно, поскольку основная прелесть ASP — это простота и интерпретация... Т.е. чтобы поправить скрипт, нужно всего-то в текстовом файле строчку перебить... А это гораздо быстрее компиляции.
И здесь то же самое. Всё зависит от того — где именно придётся эту строчку перебивать. Это и для ASP справедливо, и для JSP, и для CSP. Вобщем-то, если, например, нужно чуть подправить атрибут тега — то это в любой xSP будет сделано одинаково при одинаковом дизайне приложений.

S>- Декларируемая скорость исполнения, это хорошо, конечно, но если я (как пользователь) сижу на модеме, то мне что 63 миллисекунды, что 310 — по барабану...(взято из их тестов). Загрузка по сети определяется для меня десятками секунд.
Зато это ох как не безразлично самому серверу и тем, кто его покупает и содержит (амортизирует всяко и т.п.), потому что снижение нагрузки на центральный процессор влечёт снижение требований к аппаратуре.

S>- с точки зрения разработчика — есть ASP.NET — пишите на здоровье. Есть всё что нужно. И скорость не многим ниже.
Всё хорошо в комплексе. Под комплексом я имею ввиду комплекс харатеристик: скорость обработки, выразительные возможности языка и т.п.

S>- на сложных веб приложениях основное время, как правило, затрачивается не на непосредственную интерпретацию кода, а на использовании внешних вызываемых сервисов (например, обращение к базе данных, XSLT трансформация и т.п.)
Ну, это как раз место для использования C++.

S>Т.е. получается, что на простых проектах возможности данного продукта не требуются, а на сложных не являются определяющими.
S>Таким образом, продукт может занять только небольшую нишу, где требуется высокоскоростная серверная обработка или обслуживание большого количества пользователей одновременно. Да и то во втором случае задача ограничена.
Ай да Spidola, ай да сукин сын! (c)АСП. Мы сейчас как начнём бодаться из-за определений "простой/сложный", так мухи не то, что к стерне прижмутся, а в норы к мышам попрячутся.

S>В плюс ко всему сказанному можно добавить возможные проблемы с хостингом.
С публичным хостингом — да. Если хостером является контора-разработчик сайта, то этот значимость этого фактора снижается.

S>Но в некоторых случаях, согласен, действительно находка.
Да, я думаю, что для программ типа ClearQuest, которые содежат собственный Web-интерфейс, самое то.

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

S>>>Но в некоторых случаях, согласен, действительно находка.
ГВ>> Да, я думаю, что для программ типа ClearQuest, которые содежат собственный Web-интерфейс, самое то.
S>Мне первое что на ум пришло — сервер для онлайнового преферанса
Кстати, тоже вариант — игроков много может оазаться.

Spidola -> Re[3]: C++ server pages, однако

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

Это все решается кластеризацией. Причем мощность наращивается очень просто.
Т.е. проще купить еще одну железку за Nтыс, чем трах.. (зачеркнуто)мучиться
с созданием и отладкой приложения на С++.

S> В плюс ко всему сказанному можно добавить возможные проблемы с
S> хостингом.

Кто выбрал С++ — тот сложностей не боится

<!-- Yury Kopyl aka hrg | Гордость мешает доходам! -->

Геннадий Васильев -> Re[6]: C++ server pages, однако

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

S>>>>Но в некоторых случаях, согласен, действительно находка.
ГВ>>> Да, я думаю, что для программ типа ClearQuest, которые
ГВ>>>содежат собственный Web-интерфейс, самое то.
S>>Мне первое что на ум пришло — сервер для онлайнового преферанса
: Кстати, тоже вариант — игроков много может оазаться.

любите вы господа, велосипеды изобретать — www.gambler.ru — наш выбор

<!-- Yury Kopyl aka hrg | Хоббиты — маздай! Мордовия — фарева! -->

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

hrg>Геннадий Васильев -> Re[6]: C++ server pages, однако

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

S>>>>>Но в некоторых случаях, согласен, действительно находка.
ГВ>>>> Да, я думаю, что для программ типа ClearQuest, которые
ГВ>>>>содежат собственный Web-интерфейс, самое то.
S>>>Мне первое что на ум пришло — сервер для онлайнового преферанса
hrg>: Кстати, тоже вариант — игроков много может оазаться.

hrg>любите вы господа, велосипеды изобретать — www.gambler.ru — наш выбор

Мы рассматриваем применимость новых технологий к велосипедам. Так сказать, проверяем алгеброй гармонию .

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

hrg>Уже давно все написано и подключается как библиотеки
А вы, батенька, провокатор!

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

V>Хотя, при желании можно прилично побороться и с такой проблемой. Например, выделить прикладным модулям свой heap в виртуальном адресном пространстве, которое с обоих сторон окружено "дырами" в виртуальной памяти. Тогда наиболее частые причины падения, типа переполнения стека и выход за границы массива будут что-то портить или в самом прикладном модуле, или натыкаться на несуществующую память и просто генерить эксепшн.
А какого размера должны быть эти дыры? Хот какого бы размера они небыли всеравно гарантии стабильности системы не будет.