+  HandyCache форум
|-+  Главная категория» Новые предложения» Предложения по работе скриптов
Имя пользователя:
Пароль:
Страниц: [1] 2 3 4  Все   Вниз
  Отправить эту тему    Печать  
Автор Тема: Предложения по работе скриптов  (Прочитано 41407 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« : 01 августа 2008, 10:25:42 »

Предлагаю не выделять скрипты как "государство в государстве", а встроить работу с ними в общую логику работы с программой:
- скрипты вызывать из соответствующих списков. Например, правило списка "Не обновлять" *in:dont_update_file_by_size ^handycache\.ru вызовет соответствующий скрипт обработки ответа для УРЛов офсайта. Если ни к какому другому списку скрипт не относится, включать его в "Серверы-посредники";
- hc_action и lua.lst убрать;
- переменную hc_header_replace заменить на script_fired - признак того, считается или нет скрипт сработавшим (по умолчанию false).
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #1 : 01 августа 2008, 12:08:33 »

Не буду говорить сразу нет, но идея мне на первый взгляд не понравилась. Давайте обсудим, может я и не прав.
Скрипты ведь существенно отличаются от правил, смешивание скриптов и правил приведет к непониманию и путанице. Правила работают с URL, скрипты пока с заголовками (кто знает может еще какие-то появятся). Техника работы со скриптами и правилами с точки зрения пользователя разные, требует разной квалификации. Далеко не все скрипты можно "прописать" в каком-либо списке, какие-то из них могут выполнять функции, свойственные сразу нескольким спискам. Захочешь изменить какой-то скрипт, искать его придется по всей программе.
Цитировать
- hc_action и lua.lst убрать;
Как же их убрать, если сам пишешь
Цитировать
Если ни к какому другому списку скрипт не относится, включать его в "Серверы-посредники";
Сейчас у нас вся работа со скриптами собрана в одном месте, скрипты для запросов и ответов группируются отдельно друг от друга. По моему это правильно.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #2 : 01 августа 2008, 14:58:34 »

Правила и скрипты - это обработчики HTTP-сообщений. Их сущность одинакова. Скрипты могут обрабатывать те же элементы сообщений, что и правила (УРЛ) и плюс к этому другие заголовки. В добавок скрипты могут делать еще чего-нибудь но опять же в привязке к обработке сообщений. С точки зрения их функцинирования, правила - частный случай скриптов. По сути, правила - это более удобная для пользователя запись скриптов определенного вида. Точно так же как запись правила с "+" - это более простая запись регэкспов определенного вида.
Есть общие глобальные категории действий с HTTP-сообщениями, которые лежат в основе логики работы НС: блокировать, не обновлять, писать в кэш, запрещать все это,... Имхо, логичным было бы, чтоб все, что относится к одной категории, находилось в одном месте.
Блокировка по УРЛ находится в списке Ч, блокировка по Content-Length в настройках, а по Content-Type или AnswerCode в Серверах-посредниках и во внешних файлах. Проще (пользователю), имхо, было б когда бы они находились в одном разделе, описывающем все случаи блокирования.
Точно так же по другим категориям. К примеру, не обновлять по УРЛ сейчас находим в списке Н, а не обновлять по Content-Length - в скрипте во внешнем файле, управление которым находится в серверах-посредниках.
Кстати, я за то еще, чтоб скрипты жили не в отдельных внешних файлах, а в тех же файлах, что и нынешние списки. В правиле даже не надо для них специальной лексики создавать (о которой я писал постом выше типа *in:dont_update_file_by_size ^handycache\.ru). В строке правила можно придумать маленькую кнопочку, нажав которую раскрывался б любой указанный в настройках редактор (например, Блокнот или встроенный) с возможностью правки содержимого.
Цитировать
- hc_action и lua.lst убрать;
Цитировать
Как же их убрать
А что при описанном раскладе может содержать hc_actiоn?
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #3 : 01 августа 2008, 15:48:10 »

Цитировать
Правила и скрипты - это обработчики HTTP-сообщений. Их сущность одинакова.
Про сущность не согласен. Их назначение в какой-то мере совпадает, с этим соглашусь.
Ты же не предлагаешь слить все списки в один? А почему? Они же все обработчики HTTP-сообщений.
Цитировать
По сути, правила - это более удобная для пользователя запись скриптов определенного вида. Точно так же как запись правила с "+" - это более простая запись регэкспов определенного вида.
Это не так. Правила с "+" и без на самом деле почти одно и то же. Внутри НС правила с "+" преобразуются в правила без "+", так и существуют. Про скрипты ничего похожего не скажешь.
Цитировать
Есть общие глобальные категории действий с HTTP-сообщениями, которые лежат в основе логики работы НС: блокировать, не обновлять, писать в кэш, запрещать все это,... Имхо, логичным было бы, чтоб все, что относится к одной категории, находилось в одном месте.
Для тебя списки - это образ функций, а для меня списки - это инструменты. Скрипты - просто еще один вид инструментов. Я знаю какую работу я могу выполнить каждым из этих инструментов и знаю, где его искать.
Инструменты, встроенные в программу можно пересчитать, составить закрытый список. Составить же закрытый список всех функций я не возьмусь, о некоторых из них я могу даже не догадываться. Как же можно строить интерфейс на основе того, что нельзя даже пересчитать?
Цитировать
Блокировка по УРЛ находится в списке Ч, блокировка по Content-Length в настройках, а по Content-Type или AnswerCode в Серверах-посредниках и во внешних файлах. Проще (пользователю), имхо, было б когда бы они находились в одном разделе, описывающем все случаи блокирования.
В таком случае нужно вообще менять концепцию построения пользовательского интерфейса. Тогда нужно предлагать не сабж, а новый взгляд на интерфейс хотя бы сколько-нибудь продуманный и поднобно описанный.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #4 : 01 августа 2008, 16:26:37 »

Ты же не предлагаешь слить все списки в один? А почему? Они же все обработчики HTTP-сообщений.
Давно именно это и предлагаю. Но эта тема не об этом.
Цитировать
По сути, правила - это более удобная для пользователя запись скриптов определенного вида. Точно так же как запись правила с "+" - это более простая запись регэкспов определенного вида.
Цитировать
Это не так.
Хм... Какое правило невозможно повторить скриптом? Ответ - нет такого правила. Тогда в чем же смысл этих правил как не в предоставлении намного более удобной для пользователя формы обработки?
Цитировать
Как же можно строить интерфейс на основе того, что нельзя даже пересчитать?
Ошибаешься. Список полностью закрыт возможным набором значений переменной hc_action.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #5 : 01 августа 2008, 17:16:01 »

Цитировать
Хм... Какое правило невозможно повторить скриптом? Ответ - нет такого правила. Тогда в чем же смысл этих правил как не в предоставлении намного более удобной для пользователя формы обработки?
Когда я писал "Это не так", я имел ввиду, что нельзя сравнивать разницу между правилами с "+" и без него с одной стороны, и разницу между правилами и скриптами с другой. Ведь об этом же я там дальше пишу.
Скрипты нельзя рассматривать как замену правилам, все, что можно сделать правилами нужно делать правилами. Это и проще и менее ресурсоемко. А скрипты нужно использовать там, где правила не могут помочь.
Если согласиться с тем, что ты там написал, то нужно сначала поставить знак равенства между правилами с "+" и без, а следом приравнять правила и скрипты. Так вот с этим я и не согласен. Возможности скриптов гораздо богаче уже сегодня не говоря даже о их потенциальных возможностях. Да ты и сам это понимаешь, ведь ты же сам пишешь в первом сообщении
Цитировать
Если ни к какому другому списку скрипт не относится, включать его в "Серверы-посредники";
Цитировать
Ошибаешься. Список полностью закрыт возможным набором значений переменной hc_action.
Вероятно ты имеешь в виду функции скриптов (я там говорил о функциях всего НС). Но даже они не ограничиваются состоянием переменной hc_action. Уже сегодня можно изменить заголовок ответа, в следующей версии можно будет изменять заголовок запроса, отвечать клиенту прямо из скрипта, управлять ограничением скорости, управлять работой списков в зависимости от какого юзера поступил запрос, да и мало ли чего еще мы со временем придумаем.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #6 : 02 августа 2008, 19:16:22 »

Цитировать
Уже сегодня можно изменить заголовок ответа, в следующей версии можно будет изменять заголовок запроса, отвечать клиенту прямо из скрипта, управлять ограничением скорости, управлять работой списков в зависимости от какого юзера поступил запрос, да и мало ли чего еще мы со временем придумаем.
Это ж здорово, что скриптами можно делать что-то еще. Я вроде и не возражал против этого. Просто это "что-то еще" я пока отнес к hc_action="пусто". Волнует та часть скриптов, которая будет находиться в общей и без того немеряной куче и делать при этом операции (блокировать и др.), являющиеся основными в логике программы и уже имеющие свое средоточие в интерфейсе.
Как быть, когда у пользователя 100 скриптов? У каждого из этих ста свое имя файла на английском языке. Получится ли комфортно плыть в таком море? Будет скрипт, блокирующий такие-то УРЛы для пользователей таких-то, блокирующий такой-то Content-Type для пользователя такого-то, при запросе таких-то УРЛ блокирующий и подающий звуковой сигнал, блокирующий... Все это будут блокирующие скрипты в общей куче скриптов. Не проще ли пользователю их видеть и править в Черном списке? Список перестанет быть привязанным только к регэкспам, а будет сосредоточивать весь спектр условий, необходимых для реализации конкретной основной функции прокси-сервера (в данном случае, блокировки).
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #7 : 03 августа 2008, 11:38:31 »

Цитировать
Это ж здорово, что скриптами можно делать что-то еще. Я вроде и не возражал против этого.
Так вот я и хочу, чтобы этого "чего-то еще" было больше и пользователи скорее получили доступ к этим новым возможностям. Реализация этого твоего предложения довольно трудоемкая, а их полезность, по моему мнению, не покроет требуемых затрат времени.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #8 : 03 августа 2008, 19:25:55 »

- скрипты вызывать из соответствующих списков.
...
- hc_action и lua.lst убрать

Мне тоже не нравится эта идея. Один скрипт в зависимости от заголовков может выдавать совершенно разные действия, поэтому отнести его к какому-то одному списку нельзя. К примеру, скрипт save_or_block_403_and_404.lua выдает "save" или "stop" и поэтому в равной степени его можно отнести и к списку "З", и к списку "Ч". Если еще убрать hc_action, то такой скрипт вообще не сможет работать!
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #9 : 04 августа 2008, 15:25:14 »

DenZzz
Такой скрипт нарушает доселе строившуюся логику программы. Если его разделить на два, то один был бы в Черном списке и при срабатывании сразу прекращал бы обслуживание любых дальнейших скриптов (блокирующих, необновляющих, пишущих в кэш). Второй исполнялся б только когда мы убедились, что этот ответ не блокируется и не берется из кэша и тоже обрубал бы дальнейшие скрипты. Это бы согласовывалось с общей логикой НС.
По нынешней логике, будут работать все нижележащие скрипты. Это неэффективно, да и непросто для освоения пользователем.

Теперь представь, что я хочу, чтоб ответы-404-не-картинки блокировались, и дальше никаких блокирующих, необновляющих, пишущих в кэш скриптов бы не выполнялось. А если 404 - это картинка, то пусть она грузится из интернет и сохраняется в кэш, но только если ее не блокирует на других основаниях какой-либо еще скрипт. Это то, чего я реально хочу от скрипта save_or_block_403_and_404. Как это сделать с учетом того, что ниже него я могу добавлять другие скрипты?

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

Еще прошу спрогнозировать в уме и распространить нынешнюю логику построения lua.lst на число скриптов около 100. Просто будет во всем этом разобраться? Будут ли эффективно выполняться скрипты (например, получится ли прекратить дальнейший заведомо бесплодный анализ кучи оставшихся скриптов после принятия решения о блокировке ответа скриптом "двойного назначения")?
« Последнее редактирование: 04 августа 2008, 15:36:42 от Михаил » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #10 : 04 августа 2008, 23:21:39 »

Если его разделить на два, то один был бы в Черном списке и при срабатывании сразу прекращал бы обслуживание любых дальнейших скриптов (блокирующих, необновляющих, пишущих в кэш). Второй исполнялся б только когда мы убедились, что этот ответ не блокируется и не берется из кэша и тоже обрубал бы дальнейшие скрипты.

И в большинстве случаев получим лишнюю двойную работу по проверке одних и тех же заголовков/условий в случае, когда "stop" в списке Ч не сработал! Это эффективно?

Цитировать
По нынешней логике, будут работать все нижележащие скрипты. Это неэффективно

Как уже упоминалось ранее, затраты ресурсов/времени на обработку скриптов мизерны...

Цитировать
А если 404 - это картинка, то пусть она грузится из интернет и сохраняется в кэш, но только если ее не блокирует на других основаниях какой-либо еще скрипт. Это то, чего я реально хочу от скрипта save_or_block_403_and_404. Как это сделать с учетом того, что ниже него я могу добавлять другие скрипты?

Внеси в нужные скрипты проверку на то, что переменной hc_action еще не было присвоено определенное действие. Как, например, я сделал в скрипте block_long_file.lua.

Цитировать
Еще прошу спрогнозировать в уме и распространить нынешнюю логику построения lua.lst на число скриптов около 100. Просто будет во всем этом разобраться?

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

Цитировать
Будут ли эффективно выполняться скрипты (например, получится ли прекратить дальнейший заведомо бесплодный анализ кучи оставшихся скриптов после принятия решения о блокировке ответа скриптом "двойного назначения")?

Можно ввести в скриптах какую-нибудь новую переменную, скажем, hc_stop_script, при присвоении которой значения "true" прекращать обработку следующих скриптов. Только нужно ли это...
« Последнее редактирование: 04 августа 2008, 23:26:02 от DenZzz » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #11 : 05 августа 2008, 09:57:57 »

Цитировать
И в большинстве случаев получим лишнюю двойную работу по проверке одних и тех же заголовков/условий в случае, когда "stop" в списке Ч не сработал! Это эффективно?
Получится эффективнее, чем сейчас. Блокирующий скрипт ставим в низ списка Ч, и он исполняется только если не сработала ни одна другая блокировка. Пишущий в кэш скрипт ставим в конец списка З, и он работает только когда ответ сервера не 200/301/302.
Цитировать
Как уже упоминалось ранее, затраты ресурсов/времени на обработку скриптов мизерны...
Все относительно. Они велики, например, по сравнению с затратами на выполнение правил. Если я правильно помню, выполнение кода скрипта в 5-700 раз (в зависимости от задачи) медленнее работы машинного кода. Эти затраты будут сказываться, учитывая сетевой характер приложения. Я не принимаю во внимание нынешнее положение, когда при каждом запросе скрипты заново читаются с диска и компилируются. Это вообще катастрофа для нагруженного сервера. Но я думаю, последняя проблема все же временная.
Выработанная до этого в НС логика списков заточена под экономию системных ресурсов. Сработавшее правило автоматически блокирует проверку остальных уже заведомо ненужных.
Цитировать
Не сложнее, чем разобраться в сотне правил. Можно сгруппировать скрипты по их назначению. Да и вообще, не представляю, зачем нужна сотня скриптов и почему нельзя проверку схожих условий сделать в одном скрипте.
Имхо, гораздо сложнее из-за того что порядок следования имеет значение, могут возвращаться разные hc_action. Группировать будет тяжело, если будут скрипты "двойного назначения". И сложнее писать новый скрипт, т.к. при его вставке пользователю приходится учитывать вопросы порядка следования и прослеживать состояние глобальных переменных. Когда скриптов 5-6, это не страшно. Но когда их много, думаю, может быть тяжко. Много же их должно быть, имхо, просто по определению, иначе зачем было затеваться.
Если же часть скриптов находится в списках, то они:
- не зависят от порядка следования;
- разгружают список оставшихся скриптов;
- выполняются не обязательно до "правил", а и посреди, и после;
- их легко и наглядно включать/отключать галкой в списке.
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #12 : 05 августа 2008, 10:31:47 »

На самом деле немножко не о том спорите. Регексп - это тоже скрипт на соответствующем языке.
И вызывать скрипты из правил в принципе неплохо. Но наверно имеет смысл сильно упростить формат вызова
Т.е. в поле "правило" вместо регекспа пишем <префикс>файл:функция, функция должна вернуть true/false (сработал/не сработал), акция определяется списком откуда вызван.
При вызове из непреобразующих списков (т.е. всех кроме "преобразования" и "переадресации") глобальные переменные - только на чтение.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #13 : 05 августа 2008, 11:26:19 »

В следующей версии в скрипты будут добавлены переменные
hc_cache_file_age
hc_cache_file_content_type
hc_cache_file_size
hc_method
hc_user_name
hc_user_from_internet
hc_user_from_cache
hc_user_to_internet
hc_user_speed_limit
hc_file_speed_limit
hc_answer_body
Думаю их смысл понятен по именам. Область применения скриптов расширится и будет расширяться дальше.
Все эти новые возможности не укладываются в существующие списки. Так стоит ли устраивать переполох, чтобы пристроить 10% скриптов?
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #14 : 05 августа 2008, 12:14:53 »

Цитировать
Т.е. в поле "правило" вместо регекспа пишем <префикс>файл:функция, функция должна вернуть true/false (сработал/не сработал), акция определяется списком откуда вызван.
В точности об этом и говорю. Разница в деталях - предлагал не заморачиваться с файлами, а держать весь скрипт прям в списке.
Цитировать
В следующей версии в скрипты будут добавлены переменные
Отличная новость. Особенно про hc_answer_body.
Цитировать
Область применения скриптов расширится и будет расширяться дальше... Так стоит ли устраивать переполох, чтобы пристроить 10% скриптов?
Имхо, стоит. Только не переполох устраивать, а продумывать загодя, не допуская сваливания всего в трудноразгребаемую кучу и не забывая за расширением функциональности про вопросы эффективности программы, а также дружелюбности и простоты ее общения с пользователем и внутренней логической стройности.
Представь, что нынешние списки мы сольем в файл rules.lst. Будет хорошо?
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #15 : 05 августа 2008, 12:34:31 »

Цитировать
Имхо, стоит. Только не переполох устраивать, а продумывать загодя, не допуская сваливания всего в трудноразгребаемую кучу и не забывая за расширением функциональности про вопросы эффективности программы, а также дружелюбности и простоты ее общения с пользователем и внутренней логической стройности.
Кто бы возражал, если бы твое предложение было универсальным? На самом же деле оно применимо только к небольшой части скриптов. При этом некоторые из них придется разбить на части или наложить другие ограничения. В результате на самом деле мы получим снижение эффективности, скрипты с похожим назначением, разбросанные по всем спискам. Какая у тут стройность?
Цитировать
Представь, что нынешние списки мы сольем в файл rules.lst. Будет хорошо?
Ну я то этого никогда не предлагал. Я вообще не сторонник резких телодвижений в данном случае потому, что для меня они закончатся большой работой. Мне больше нравится когда работы мало, а эффект большой.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #16 : 05 августа 2008, 17:53:34 »

Цитировать
В результате на самом деле мы получим снижение эффективности, скрипты с похожим назначением, разбросанные по всем спискам.
Если ты читал предыдущие посты, то знаешь, что этого не получится. И что эффективность ниже сейчас.
Цитировать
Я вообще не сторонник резких телодвижений в данном случае потому, что для меня они закончатся большой работой. Мне больше нравится когда работы мало, а эффект большой.
Можно выносить предварительно на обсуждение: "Хочу сделать так-то. Давайте помыслим, как это будет лучше". А сейчас да, я представляю, что не хочется что-то переделывать и одно это обеспечивает негативный угол зрения на предложения по изменению. Аргументы просто отбрасываются и все.
Утрируя, могу провести параллель (без обид), что проще всего дать пользователю С++ и пусть он сам все пишет. Гибкость максимальная, эффект большой, автору делать вообще ничего не надо. Только достаточно ли этих двух вещей для наслаждения пользования программой? Для меня - нет. Иначе я бы юзал сквид.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #17 : 05 августа 2008, 19:43:38 »

Цитировать
Если ты читал предыдущие посты, то знаешь, что этого не получится. И что эффективность ниже сейчас.
На самом деле в данном случае, как это обычно и бывает, есть и плюсы и минусы. Утверждать однозначно, что эффективность от  реализации твоего предложения повысится я бы не стал.
Цитировать
Можно выносить предварительно на обсуждение: "Хочу сделать так-то. Давайте помыслим, как это будет лучше".
Я так и делаю, когда чувствую, что сам по каким-то причинам не могу принять решения (советоваться вообще по всем вопросам, согласись, нереально). Свежий пример - проблема персонализации кэша. Что касается скриптов, то их появление было для всех сюрпризом, в том числе в какой-то мере и для меня. Утром я еще не знал, что вечером буду делать скрипты. У меня родилось вдохновение их сделать и если бы я не мог их сделать быстро, их бы не было совсем. И сейчас, мне не кажется, что они не на месте. Если работать с ними кому-то не сложно или не нравится, можно их просто игнорировать. На работу остальной части НС они никак не влияют (даже не увеличивают размер программы, достаточно убрать dll).
Цитировать
Аргументы просто отбрасываются и все.
Возможно я невнимательно читал, но я вижу один аргумент: желание управление каждой функцией сконцентрировать в одном месте. Если я ошибаюсь, то сформулируй, какие аргументы я пропустил.
Против самого этого желания я ничего не имею, желание справедливое. Однако реализация твоего предложения положения существенно не изменит, а работы потребует много.
Цитировать
Утрируя, могу провести параллель (без обид), что проще всего дать пользователю С++ и пусть он сам все пишет. Гибкость максимальная, эффект большой, автору делать вообще ничего не надо. Только достаточно ли этих двух вещей для наслаждения пользования программой? Для меня - нет. Иначе я бы юзал сквид.
Я же не писал, что не хочу делать вообще ничего. Просто из-за ограниченности времени я вынужден выбирать, что делать, что отложить, а от чего вообще отказаться. Можно, конечно, обещать сделать все. Все будут довольны, но недолго.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #18 : 09 августа 2008, 09:05:07 »

Тут еще подумалось. Может быть желание исполнить какое-то действие только после того как стало известно, что файл, например, не блокируется или что он, например, точно пишется в кэш, после того как он полностью загружен из сети и т.п. Имхо, полезно было б иметь и другие точки вхождения для скриптов, не только нынешние две. Это, пожалуй, сможет быть равносильным введению плагинной системы.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #19 : 09 августа 2008, 11:54:24 »

Может быть желание исполнить какое-то действие только после того как стало известно, что файл, например, не блокируется или что он, например, точно пишется в кэш, после того как он полностью загружен из сети и т.п.

А есть ли в этом практическая необходимость? Приведи пару примеров, когда без этого не обойтись имеющимися средствами.

После того, как стало известно, что файл:
  • не блокируется - и сейчас в сриптах ответов можно с ним делать, что угодно. Поставь последним скриптом и введи проверку на значение hc_action.
  • полностью загружен из сети - после драки кулакими не машут! Что ты хочешь делать, когда файл уже полностью загружен и передан клиенту?
  • пишется в кэш - аналогично. Что это меняет? Как влияет на наше решение?
Сообщить модератору   Записан
Страниц: [1] 2 3 4  Все   Вверх
  Отправить эту тему    Печать  

 
Перейти в: