|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 05 Sep 2005 23:08:18
To : Sergey Skvortsov
Subject : perl модули
--------------------------------------------------------------------------------
05 Sep 05, Sergey Skvortsov writes to Slawa Olhovchenkov:
>> А можно кратенько для тех кто в танке и все пропустил?
>> А то я сейчас man perlmod читаю и основная суть от меня что-то
>> ускользает.
А по внутренностям того, что внутри модуля -- разница есть?
SS> "require My::Module" - это как "require /path/to/My/Module.pm", но
SS> загружается лишь единожды.
Что значит "единожды"?
SS> "use My::Module (@args)" - это лишь "require My::Module;
SS> My::Module->import(@args)".
SS> в целом "require" используется ну очень редко.
редко? почему?
SS> use My::Module;
SS> use My::Module::Admin;
SS> use My::Module::User;
Вот от такого списка хочется избавится. Хочется просто понакидать в каталог
нужный набор модулей, а тут автомагическим циклом его активировать. В целом
понято -- в центральном скрипте readdir с require "$file", в модуле что-то типа
BEGIN { $main::common_hash{'ident_module'} = \&sub_module; };
>> Hе suexec. suidный скрипт. И как ты предлагаешь мне sudo в mod_perl
>> применять? Мне из скрипта надо выполнить модификацию фалов, недоступных
>> на запись апачу и ты предлагаешь что?
SS> либо делать system("sudo -u root /path/to/script"), где sudo разрешен
SS> для www, либо делать отдельный демон (громко сказано), который висит под
SS> нужным uid/gids принимает запроса и выполняет их. Идеально для этого
SS> POE, хотя нетривиально на первый раз. Или тупо xinetd на localhost.
SS> mod_perl - это в первую очередь либа, прилинкованная к apach'у и
SS> хранящяя некое общее состояние между процессами (у нас же preforked
SS> model?). требовать от него suexec - как требовать этого от libxml.
Вот-вот. Поэтому я лучше suidный скрипт. Оно как-то проще. И файлов -- меньше.
>> Берем скрипт под mod_perl. Ставим. Думаем -- надо поправить. Создаем в
>> апаче еще один виртуальный хост для отладки, копируем туда этот скрипт,
>> модифицируем его. И о, черт, у нас в двух скриптах венигрет из старых и
>> новых имплементаций. Уж не помню куда что попадало, но никакой изоляции.
>>
>> Что-то изменилось в этом плане?
SS> Код является общим для процесса(ов). Виртуальные хосты - это лишь
SS> контексты.
SS> Проблемы не будет, если разбить скрипт на packages.
Там где-то обещалось, что он автоматом разбивается. Имя packages совпадало с
именем то ли url до скрипта, то ли пути в файлухе. Hо не суть, дебажная-то
версия все равно имела в названии дополнительную цифирь 2.
Hе, я не против mod_perl. Hо только при большой нужде и хорошо подумавши перед
каждым шагом, тащательно придумывая имена, дабы в страшном сне конфликта имен не
получить. И после вдумчивого штудирования всего попало. И желательно что бы при
этом на хостинге больше ничего и близко не было.
Hо это не мой случай.
... Hе говори глупостей - враг подслушивает!
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
