По поводу имен переменных — Вы правы, конечно.
Но, на мой взгляд, написать вместо $d что-нибудь типа $input_data — это превратить легкий компактный скрипт в более громоздкий.
Поэтому удобочитаемыми сделал только имена функций. А классы не стал делать за ненадобностью :-)
Раздавать права по IP — хорошая идея. В скрипт не включил только из-за того, что IP-адреса у многих провайдеров динамические. А в локальной сети ограничения, наверное, не нужны…
Ну вот и применение нашлось :-). А Вы правда посчитали экономию? Дело в том, что PDF-документы, генерируемые скриптом, содержат не текст, написанный шрифтами, а, фактически, картинки. Поэтому они больше, чем обычные PDF-ки.
Я в общем согласен со всеми комментариями по поводу вирусов, какие они должны быть, и как они работают.
Но, по моему скромному мнению, вирусы пишут либо зеленые мелкие, возомнившие себя мега-хакерами, либо (очень прошу простить за грубость) люди с маленьким ***м, которые не могут по-другому решить свои какие бы то ни было проблемы.
Потому что обмануть с помощью вируса среднестатистического пользователя сети — это же как отнять конфетку у ребенка. Но есть же цивилизованные способы заработать денег и приподняться, чем воровать конфеты! Разве не так?
Вирус, который имеет внутри себя библиотеку для регулярных выражений? На мой взгляд, маловероятно :-)
Ведь это не линукс, который невозможно представить без libpcre.so.0
Windows XP на всех компьютерах, о которых удалось узнать хоть что-то.
Идея интересная — можно попробовать на Vista руками запустить route и посмотреть, будет ли «решалка проблем» возникать
Ага. Самое парадоксальное — что стандартная команда route без проблем добавляет маршрут через шлюз с 0 на конце. Я не очень помню теорию сетей, но ведь так вроде не должно быть…
По сути, это одно и то же. Работа через IPP — это передача документов определенного типа application/ipp по протоколу HTTP(S). Сервер печати CUPS устроен таким образом: если клиент смотрит страничку localhost:631 через браузер, то он видит обычные HTML-страницы, а если клиент отправляет на этот URL данные IPP, то получает ответ в соответствии со спецификацией IPP.
Зря вы так, очень даже читал мануал к CUPS. Не могу похвастаться, что от корки до корки, но до Windows Vista особых проблем с настройкой принтеров — как реальных, так и виртуальных, с написанием собственного backend'а, не испытывал.
Тот факт, что «обычная» Vista не может распечатать на «обычном» Linux-принтере, никак не отражен в документации к CUPS. Пост не претендует на «первооткрывательство» — он в блоге Linux, а не в блоге Vista, но про настройку CUPS я даже и не пишу — все действительно изложено в документации и в статьях.
Наоборот, рассказывается, как решить конкретную задачу (или проблему, если хотите). Решение было найдено с трудом, поэтому, на мой взгляд, пост вполне уместен.
Вы совершенно правы!
Правда, признаюсь, я не ассоциировал IPP с таким способом «печати на URL» — в Linux есть почти все необходимые драйвера PPD, и IPP я не использовал, а в Windows термин Internet Printing Protocol не упоминается.
Спасибо за уточнение!
Виноват, конечно же, не FastCGI, понимаю вашу иронию.
Виновата чаще всего реализация fastcgi-сервера. Ну сами подумайте: люди разрабатывают веб-серверы, которые оптимизированы, и проверены, и т.п. (пример тому — и Apache — не смейтесь, и nginx).
И тут появляется идея FastCGI, все ее одобряют (идея действительно супер), но оказывается, что вся логика веб-сервера должна быть и в FastCGI-демоне (или в модуле, который стартует FastCGI): слежение за сбойными процессами, автоматический запуск, если FastCGI сломался, и т.п. И, по всей вероятности, в случае с PHP разработчики так до конца и не определились, кто должен эти действия выполнять: веб-сервер или fastcgi-процесс. Оттуда и ошибки были…
Не спорю, что при правильной реализации FastCGI все будет просто здорово.
У Perl не все хорошо с потокобезопасностью. Как и у v8, кстати. А вот у TraceMonkey все в порядке. И поэтому мне, в идеале, хотелось бы создать модуль с асинхронным handler'ом, который на время выполнения скрипта не блокировал бы рабочий процесс, а спокойно выполнялся бы в отдельном потоке. И я предвижу, что вы скажете, что потоки — это зло, а вот event loop и все такое — это круто… Но, в то же время, вынужден признать, что пока идея с несколькими Javascript-thread'ами — всего лишь идея, и пока она не реализована — уныние мы еще не победили :-)
Ваши советы точны и по существу, приятно, что вы заглянули в исходники.
Тогда у меня к вам встречный вопрос. Не знаете ли вы, как можно реализовать асинхронный handler в nginx? А то из nginx я знаю только Игоря Сысоева, но не лично и не по переписке (кто ж его не знает). У Emiller'а — два притопа — три прихлопа, для новичков, правда, в самый раз…
Вот как бы так сделать, чтобы handler, описанный в модуле, не блокировал весь процесс, а стартовал отдельный thread и возвращал, например, NGX_AGAIN, а thread тем временем бы выполнял скриптик, вызывал бы фильтры, и т.п.
Потому что как сейчас сделано — мне самому не нравится. И, если сделать одновременное выполнение многих скриптов в одном worker-процессе — тогда, согласитесь, и thread-safe нужен.
Согласен с вами. Причем множество фреймворков уже наблюдается :-)
Единственное что — многие написаны на C++ (а не на C) и/или используют свою систему работы с памятью. Не всегда оптимальную, кстати (по сравнению с nginx, который использует не malloc, а выделение памяти из pool'а.
Поэтому «прикрутить» что-нибудь к проекту пока не удалось…
На самом деле, вопрос «кривости» ООП — это тот еще вопрос :-).
Раньше мне нравился PHP (когда он был еще 4). Потому что все трюки, которые можно было сделать в плане ООП — они все документированы официально. Потом появился PHP 5 и он показался мне еще более продвинутым. Но когда я увидел ООП в других языках…
— Java — хрестоматийный пример, все объектно-ориентировано, люди очень хорошо думают над дизайном классов. Но, блин, писать небольшие скриптики и постоянно думать, а не слишком ли фигово я классы назвал — это ж кошмар!
— Python — все супер, огромная standard library, но ведь тоже что-то не устраивает! А тут еще и переход на Python 3…
— Ruby — это просто ООП будущего, отличный язык… Но тут мне попадается на глаза вот эта статья, и мне как-то страшно на этом языке писать реальные программы…
— Javascript — всего по минимуму, но, в то же время, ощущение легкости и полноты. А тут еще оказывается, что server-side javascript появился относительно недавно, и есть над чим поработать…
— C++ не рассматриваю для веб-программирования уж :-)
Ну и, по сравнению со всем этим разнообразием, попытки PHP обновить свой язык, добавить в него (наконец-то!) юникод, нормальные inline-функции, и т.п., выглядят просто (извините) жалкими. А вы говорите про кривой Javascript :-)
Если, конечно, правда большой трафик через VPN на принтер идет
Но, на мой взгляд, написать вместо $d что-нибудь типа $input_data — это превратить легкий компактный скрипт в более громоздкий.
Поэтому удобочитаемыми сделал только имена функций. А классы не стал делать за ненадобностью :-)
Ну вот и применение нашлось :-). А Вы правда посчитали экономию? Дело в том, что PDF-документы, генерируемые скриптом, содержат не текст, написанный шрифтами, а, фактически, картинки. Поэтому они больше, чем обычные PDF-ки.
Но, по моему скромному мнению, вирусы пишут либо зеленые мелкие, возомнившие себя мега-хакерами, либо (очень прошу простить за грубость) люди с маленьким ***м, которые не могут по-другому решить свои какие бы то ни было проблемы.
Потому что обмануть с помощью вируса среднестатистического пользователя сети — это же как отнять конфетку у ребенка. Но есть же цивилизованные способы заработать денег и приподняться, чем воровать конфеты! Разве не так?
Ведь это не линукс, который невозможно представить без libpcre.so.0
Хорошо, что помогло
Идея интересная — можно попробовать на Vista руками запустить route и посмотреть, будет ли «решалка проблем» возникать
Но Вы, естественно правы, это самое логичное поведение вирусных программ
application/ippпо протоколу HTTP(S). Сервер печати CUPS устроен таким образом: если клиент смотрит страничку localhost:631 через браузер, то он видит обычные HTML-страницы, а если клиент отправляет на этот URL данные IPP, то получает ответ в соответствии со спецификацией IPP.pdf:/path/to/dirЕсли подробно — можно поискать в Google, я нашел www.ubuntugeek.com/how-to-create-pdf-documents-in-ubuntu.html
Тот факт, что «обычная» Vista не может распечатать на «обычном» Linux-принтере, никак не отражен в документации к CUPS. Пост не претендует на «первооткрывательство» — он в блоге Linux, а не в блоге Vista, но про настройку CUPS я даже и не пишу — все действительно изложено в документации и в статьях.
Наоборот, рассказывается, как решить конкретную задачу (или проблему, если хотите). Решение было найдено с трудом, поэтому, на мой взгляд, пост вполне уместен.
Правда, признаюсь, я не ассоциировал IPP с таким способом «печати на URL» — в Linux есть почти все необходимые драйвера PPD, и IPP я не использовал, а в Windows термин Internet Printing Protocol не упоминается.
Спасибо за уточнение!
Виновата чаще всего реализация fastcgi-сервера. Ну сами подумайте: люди разрабатывают веб-серверы, которые оптимизированы, и проверены, и т.п. (пример тому — и Apache — не смейтесь, и nginx).
И тут появляется идея FastCGI, все ее одобряют (идея действительно супер), но оказывается, что вся логика веб-сервера должна быть и в FastCGI-демоне (или в модуле, который стартует FastCGI): слежение за сбойными процессами, автоматический запуск, если FastCGI сломался, и т.п. И, по всей вероятности, в случае с PHP разработчики так до конца и не определились, кто должен эти действия выполнять: веб-сервер или fastcgi-процесс. Оттуда и ошибки были…
Не спорю, что при правильной реализации FastCGI все будет просто здорово.
Тогда у меня к вам встречный вопрос. Не знаете ли вы, как можно реализовать асинхронный handler в nginx? А то из nginx я знаю только Игоря Сысоева, но не лично и не по переписке (кто ж его не знает). У Emiller'а — два притопа — три прихлопа, для новичков, правда, в самый раз…
Вот как бы так сделать, чтобы handler, описанный в модуле, не блокировал весь процесс, а стартовал отдельный thread и возвращал, например, NGX_AGAIN, а thread тем временем бы выполнял скриптик, вызывал бы фильтры, и т.п.
Потому что как сейчас сделано — мне самому не нравится. И, если сделать одновременное выполнение многих скриптов в одном worker-процессе — тогда, согласитесь, и thread-safe нужен.
Единственное что — многие написаны на C++ (а не на C) и/или используют свою систему работы с памятью. Не всегда оптимальную, кстати (по сравнению с nginx, который использует не malloc, а выделение памяти из pool'а.
Поэтому «прикрутить» что-нибудь к проекту пока не удалось…
Раньше мне нравился PHP (когда он был еще 4). Потому что все трюки, которые можно было сделать в плане ООП — они все документированы официально. Потом появился PHP 5 и он показался мне еще более продвинутым. Но когда я увидел ООП в других языках…
— Java — хрестоматийный пример, все объектно-ориентировано, люди очень хорошо думают над дизайном классов. Но, блин, писать небольшие скриптики и постоянно думать, а не слишком ли фигово я классы назвал — это ж кошмар!
— Python — все супер, огромная standard library, но ведь тоже что-то не устраивает! А тут еще и переход на Python 3…
— Ruby — это просто ООП будущего, отличный язык… Но тут мне попадается на глаза вот эта статья, и мне как-то страшно на этом языке писать реальные программы…
— Javascript — всего по минимуму, но, в то же время, ощущение легкости и полноты. А тут еще оказывается, что server-side javascript появился относительно недавно, и есть над чим поработать…
— C++ не рассматриваю для веб-программирования уж :-)
Ну и, по сравнению со всем этим разнообразием, попытки PHP обновить свой язык, добавить в него (наконец-то!) юникод, нормальные inline-функции, и т.п., выглядят просто (извините) жалкими. А вы говорите про кривой Javascript :-)