Re: [apache-talk] php's config

[Victor Wagner <vitus@xxxxxx>]

On Tue, 18 Jan 2000, Stanislav Malyshev a.k.a Frodo wrote:

> From: Stanislav Malyshev a.k.a Frodo <frodo@xxxxxxxxxxxx>
> Subject: Re: [apache-talk] php's config
> 
> VW>> Я бы это делал через mod_perl большим большим циклом. Но у тебя не
> VW>> mod_perl, а mod_php. Всегда говорил, что php давить, в частости потому что
> VW>> из него нельзя конфигурить сервер и писать обработчики для других стадий
> VW>> запросов. mod_dtcl давить по той же причине. Этот чайник который писал,
> 
> Ага. И C давить - на нем тоже Apache конфигурить нельзя. И mod_charset
> давить - в нем тоже нельзя Апач конфигурить. И вообще все модули, кроме
> mod_perl, давить. Всем дружно хором бросать все и непрерывно конфигурить
> Апач 23 часа в сутки. Час - на сон. 

Ну, во первых на C Apache конфмгурить можно. На чем по-вашему написан
код разбора существующего конфигурационного файла? mod_charset здесь ни
при чем. Он решает свою отдельную задачу, жрет ресурсов не более, чем для
этой задачи потребно, и, кстати, неплохо конфигурится.

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

Вообще, к php и mod_dtcl у меня претензии по другой причине - нефига
встраивать код на Turing complete языке в html. Код это код, а html это
данные, и степень ответственности у их писателей принципиально разная.

Вот у себя в communiware мы проводим четкое разграничение между
программистами, дизайнерами и авторами контента. php эти вещи
смешивает. Что ни к чему, кроме дыр в секьюрити привести не может. Нет,
вру, может - к необоснованно завышенным требованиям к квалификации
дизайнера.
 
 
> VW>> вместо того чтобы сделать аналог mod_perl со всеми прелестями safe
> VW>> interpreters, сделал yet another php. Вот mod_python он вроде правильный.
> 
> Этот чайник, который писал (их там немножко больше десятка, но нас ведь
> это не волнует), безусловно, неправ. Почему он, дубина, не спросил некоего

Ах, уже больше десятка? Ну тогда стоит посмотреть на этот код еще раз.
В тот раз, когда я на него смотрел, там вроде меньше народу было. Увидел я
что конструкцию вида ?FOO=bar&FOO=baz оно не обрабатывает и дальше пошел -
как же мне без груп чекбоксов-то.
 
> В.В., ему бы все обьяснили популярно. А то развелось чайников, пишут
> всякую фигню, не спросясь, а mod_perl родной зажимают. Повбывав бы. Все

А я ему, кстати писал, и объяснял свою точку зрения. Которая заключается в
том, что основным выигрышным пунктом tcl по сравнению с perl является
система safe-интерпретаторов, которая была бы незаменимой в
web-приложениях, будь она туда корректно присобачена.
  
> модули, кроме mod_perl, запретим, а mod_perl будем преподавать в школах,
> начиная с первого класса. Ура, товарищи!

Я ненавижу perl. Я зарабатываю деньги посредством писания на нем, и с
удовольствием писал бы все то же самое на tcl, если бы это было возможно.

Но переписывать добрую половину имеющегося перлового кода на C (поскольку
mod_dtcl не заморачивается обработкой конфигурации и стадий запроса
отличных от content generation), 
и писать еще столько же и больше кода на C для того, чтобы обеспечить себе
удобное взаимодействие между теми поторохами апача которые мне нужны и
теми фичами Tcl, которые считаю целесообразными, у меня нет времени.

А фичи там такие:

1. Отсутствие проблем с перегрузкой кода при его обновлении 
2. Существенно более стройная система локализации переменных
3. Гибкий синтаксис - в большинстве случаев не нужно писать парсеры
  проблемно ориентированных языков - можно обойтись парсером Tcl и набором 
  проблемно-ориентированных процедур. Ну, может еще парочка регекспов,
  как в случае парсера HTML.
4. safe interpreters.

Вот чего недостает, так это аналога DBI. Из-за этого потребуется
дополнительная скриптовая прокладка между драйвером базы данных и
приложением, либо куча геммороя при переносе его на другой SQL-сервер.
кстати, php это тоже касается. 


> -- 
> frodo@xxxxxxxxxxxx	\/  There shall be counsels taken
> Stanislav Malyshev	/\  Stronger than Morgul-spells
> phone +972-3-9316425	/\  		JRRT LotR.
> http://sharat.co.il/frodo/	whois:!SM8333
> 
> 
> =============================================================================
> =               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
> Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
> =       Archive avaliable at http://www.lexa.ru/apache-talk                 =
> 

--------------------------------------------------
Victor Wagner			vitus@xxxxxx
Programmer			Office:7-(095)-203-50-60
Institute for Commerce 		Home: 7-(095)-135-46-61
Engineering                     http://www.ice.ru/~vitus

=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =