Спасибо за комментарий! Наконец-то я понял, зачем вели учет по $host, хотя я и не считаю, что это хорошая затея. Однако если использовать $host.md5($uri+аргументы).$binary_remote_addr, то почему тогда ботам не посылать каждый раз разный uri+аргументы?
По поводу (2). Из текста статьи мне показалось, что в бан попадет только тот, кто будет 100 раз отфильтрован за 15 минут. А для каждого «отфильтровывания» нужно подать более 1500 запросов в минуту (допустим, учет ведем всё-таки по $binary_remote_addr). Поисковик не подает запросы так часто, поэтому он не должен «отфильтроваться» nginx'ом ни разу. Кажется, суть тут в том, что бот, в отличие от пользователя, не успокоится после отфильтровывания nginx'ом и быстро наберет необходимые 100 отфильтрованных запросов. Хотя бота можно сделать и умного. Как, к примеру, отличить пользователя от бота, имитирующего неторопливое хождение по ссылкам, заполнение форм и нажатие кнопок?
Часть Заказчиков предпочитает не открывать код покупателям приложения. Ещё может так получиться, что распространять проприетарный плагин к фреймворку позволяется лицензией, а вносить изменения в код фреймворка и распространять измененный вариант без открытия кода — нельзя. Это не относится к Wt, но относится к фреймворкам, распространяемым под лицензией GNU Lesser General Public License.
Мне кажется, для написания плагина требуется не такое глубокое «погружение» в код фреймворка, как для внесения своих изменений. Если мы внесли изменения в сам фреймворк, то как быть при выходе новой версии фреймворка? Наши изменения могут оказаться несовместимыми с изменениями разработчиков фреймворка. Так что в плане сопровождения плагин выглядит привлекательнее.
Согласно википедии, сам метод переводится «Получение ресурса есть инициализация». Не встречал общепризнанного перевода RAII-класса, могу предложить лишь свой: «владелец ресурса», но он мне нравится меньше, чем «RAII-класс».
Поправлюсь: не знания, а применения. Знать их, конечно, желательно, чтобы понимать, как оно работает. Но применять их напрямую можно по минимуму. Wt позволяет подключать свои HTML, CSS и JavaScript, но для большинства задач есть встроенные инструменты, позволяющие этого избежать.
Писать HTML руками просто до тех пор, пока это простой HTML. А стоит столкнуться с элементами, которые по-разному поддерживаются браузерами, проще пользоваться библиотекой виджетов, которая снимает с разработчика необходимость следить за особенностями разных браузеров.
К примеру, для WSpinBox (поле для ввода числа) используется встроенная возможность браузера, если она доступна, в противном случае используется собственная реализация на JavaScript.
Для JavaScript проблему несовместимости браузеров можно решить при помощи JavaScript-библиотеки, например, jquery, а в данном случае решается проблема и для браузеров, в которых JavaScript недоступен.
Эффективность (скорость создания) HTML самописными генераторами может быть довольно высокой, но в случае Wt преимуществом будет использование Ajax, позволяющее генерировать не всю страницу, а лишь изменившуюся часть. Это хорошо продемонстрировано на этой странице: при прокрутке таблицы загружаются только необходимые ряды, а не вся таблица. В то же время, если JavaScript недоступен, таблица будет выводиться постранично.
Мне не доводилось работать с видео в Wt, поэтому могу лишь предположить, что можно использовать WMediaPlayer, а в качестве источника использовать свою реализацию WResource, выдающую видео, склеенное из кадров. Так как WResource по умолчанию кеширует весь ответ, а потом отдает его, при этом нужно использовать ResponseContinuation, подавая каждый раз очередной небольшой кусочек видео.
Не знаю, можно ли при этом обойтись без знания полного размера. В классе WStreamResource реализована отдача любого потока. Только, судя по его коду, полный размер потока ему таки требуется. В принципе, если допускается не полностью чистое решение, можно попробовать подать максимальную длину, которую размер потока точно не превысит.
Когда мы пишем шаблоны в Django, мы пишем при этом HTML (с надстройками, касающимися шаблонов: подстановки, условия, циклы и т.п.). То есть, без знания HTML проект на Django (или CppCMS) не сделаешь.
Кстати, в Wt тоже есть виджет, отвечающий за шаблоны. Так что если в каком-то месте удобнее писать HTML напрямую, это возможно.
Мне не доводилось писать общий код, из которого можно получить и Qt и Wt приложение. Так как их системы виджетов не связаны, а лишь похожи, сделать это сегодня будет нелегко. Разве что с кодогенерацией: заменять WPushButton на QPushButton и т.д., но не думаю, что так будут делать: классы всё-таки разные и не все методы одной библиотеки имеют аналог в дргой. Ситуацию мог бы исправить qt-backend для Wt, но его нет.
Если речь идет о приложении, которое было бы одновременно и Qt, и Wt-приложением (скажем, прикрутить веб-интерфейс на Wt к qbittorrent вместо того, что у него сейчас) — теоретически можно благодаря wtwithqt, но я этого не пробовал.
Несколько долгие ответы (особенно, время на создание сессии) могут быть связаны с нагруженностью или удаленностью сервера, где запущены демострации. При тестах нетривиального приложения на локальном компьютере ответы получаются довольно быстрые.
Приведу здесь немного цифр. Были скомпилированы release-версии приложения и библиотеки. Былы включена запись времени, затраченного на стороне сервера, в лог (запись времени можно включить, если добавить в файл wt_config.xml: <log-response-time>true</log-response-time>). Затем я открывал приложение и делал несколько действий, приводящих к перерисовке части страницы.
В Ajax версии создание сессии состояло в нескольких относительно долгих запросах около 20 мс (загрузка jquery, стилей и других файлов, которые в Ajax приложение требуется загрузить 1 раз). Большинство дальнейших действий занимали меньше 1 мс (например, 0.4 мс).
В HTML версии время на каждое действие было чуть больше (2-3 мс). Думаю, это связано с тем, что нужно было перегенерировать всю страницу, а не её часть.
Тут речь идет о времени, потраченном одним из потоков выполнения сервера (их запускается по умолчанию 10, чтобы не было простоев, например в случае работы с БД).
Чтобы ускорить соединение с сервером, можно разрешить соединяться через WebSocket (<web-sockets>true</web-sockets> в настройках), если он доступен. Я не измерял ускорение, которое при этом получается, но на глаз всё движется мгновенно.
При подходе, в котором используются виджеты, объекты, отвечающие за них, приходится хранить на сервере (иначе не получится сделать HTML-версию, аналогичную Ajax-версии). При использовании других языков возросли бы затраты ресурсов, которые пришлось бы выделять на сервере для работы с деревом виджетов. Собственно, это заметно по самому Wt: для каждой версии Wt выходит аналогичная версия jWt, написанная на Java; было замечено, что jWt оказывается примерно в 2 раза медленнее, чем release-версия Wt. Это может быть иметь значение при использовании на устройствах с ограниченными ресурсами.
В принципе, подобный подход применяется и в других библиотеках, написанных на других языках: Pyjamas (Python) и Google Web Toolkit (Java). Однако обе библиотеки не предоставляют HTML-версии, для ситуаций, когда JavaScript недоступен.
К числодробилкам часто хочется иметь веб-интерфейс. Написать его можно на том же языке, что и саму числодробилку (часто это как раз C/C++/Java). Причем задача генерации HTML перекладывается с разработчика на библиотеку: написание веб-интерфейса напоминает написание обычного графического приложения, например на Qt.
Вы правы, поэтому я написал "возможность абстрагирования". Если хочется чего-то особенного, скажем, прикрутить какой-нибудь jquery-плагин, то, разумеется, на JavaScript писать придется. Библиотека предоставляет ряд удобств, упрощающих подключение своего JavaScript: JavaScript сигналы и слоты, методы для загрузки JavaScript-библиотек и выполнения произвольного JavaScript-кода.
Но при стандартном использовании можно обойтись без использования HTML, CSS и JavaScript.
Кстати, в галерее виджетов не представлены некоторые виджеты библиотеки, например, WGLWidget для работы с WebGL.
По поводу (2). Из текста статьи мне показалось, что в бан попадет только тот, кто будет 100 раз отфильтрован за 15 минут. А для каждого «отфильтровывания» нужно подать более 1500 запросов в минуту (допустим, учет ведем всё-таки по $binary_remote_addr). Поисковик не подает запросы так часто, поэтому он не должен «отфильтроваться» nginx'ом ни разу. Кажется, суть тут в том, что бот, в отличие от пользователя, не успокоится после отфильтровывания nginx'ом и быстро наберет необходимые 100 отфильтрованных запросов. Хотя бота можно сделать и умного. Как, к примеру, отличить пользователя от бота, имитирующего неторопливое хождение по ссылкам, заполнение форм и нажатие кнопок?
Мне кажется, для написания плагина требуется не такое глубокое «погружение» в код фреймворка, как для внесения своих изменений. Если мы внесли изменения в сам фреймворк, то как быть при выходе новой версии фреймворка? Наши изменения могут оказаться несовместимыми с изменениями разработчиков фреймворка. Так что в плане сопровождения плагин выглядит привлекательнее.
К примеру, для WSpinBox (поле для ввода числа) используется встроенная возможность браузера, если она доступна, в противном случае используется собственная реализация на JavaScript.
Для JavaScript проблему несовместимости браузеров можно решить при помощи JavaScript-библиотеки, например, jquery, а в данном случае решается проблема и для браузеров, в которых JavaScript недоступен.
Эффективность (скорость создания) HTML самописными генераторами может быть довольно высокой, но в случае Wt преимуществом будет использование Ajax, позволяющее генерировать не всю страницу, а лишь изменившуюся часть. Это хорошо продемонстрировано на этой странице: при прокрутке таблицы загружаются только необходимые ряды, а не вся таблица. В то же время, если JavaScript недоступен, таблица будет выводиться постранично.
Не знаю, можно ли при этом обойтись без знания полного размера. В классе WStreamResource реализована отдача любого потока. Только, судя по его коду, полный размер потока ему таки требуется. В принципе, если допускается не полностью чистое решение, можно попробовать подать максимальную длину, которую размер потока точно не превысит.
Кстати, в Wt тоже есть виджет, отвечающий за шаблоны. Так что если в каком-то месте удобнее писать HTML напрямую, это возможно.
В галерее виджетов есть работающий пример показа видео.
Если речь идет о приложении, которое было бы одновременно и Qt, и Wt-приложением (скажем, прикрутить веб-интерфейс на Wt к qbittorrent вместо того, что у него сейчас) — теоретически можно благодаря wtwithqt, но я этого не пробовал.
Приведу здесь немного цифр. Были скомпилированы release-версии приложения и библиотеки. Былы включена запись времени, затраченного на стороне сервера, в лог (запись времени можно включить, если добавить в файл wt_config.xml:
<log-response-time>true</log-response-time>). Затем я открывал приложение и делал несколько действий, приводящих к перерисовке части страницы.В Ajax версии создание сессии состояло в нескольких относительно долгих запросах около 20 мс (загрузка jquery, стилей и других файлов, которые в Ajax приложение требуется загрузить 1 раз). Большинство дальнейших действий занимали меньше 1 мс (например, 0.4 мс).
В HTML версии время на каждое действие было чуть больше (2-3 мс). Думаю, это связано с тем, что нужно было перегенерировать всю страницу, а не её часть.
Тут речь идет о времени, потраченном одним из потоков выполнения сервера (их запускается по умолчанию 10, чтобы не было простоев, например в случае работы с БД).
Чтобы ускорить соединение с сервером, можно разрешить соединяться через WebSocket (
<web-sockets>true</web-sockets>в настройках), если он доступен. Я не измерял ускорение, которое при этом получается, но на глаз всё движется мгновенно.При подходе, в котором используются виджеты, объекты, отвечающие за них, приходится хранить на сервере (иначе не получится сделать HTML-версию, аналогичную Ajax-версии). При использовании других языков возросли бы затраты ресурсов, которые пришлось бы выделять на сервере для работы с деревом виджетов. Собственно, это заметно по самому Wt: для каждой версии Wt выходит аналогичная версия jWt, написанная на Java; было замечено, что jWt оказывается примерно в 2 раза медленнее, чем release-версия Wt. Это может быть иметь значение при использовании на устройствах с ограниченными ресурсами.
В принципе, подобный подход применяется и в других библиотеках, написанных на других языках: Pyjamas (Python) и Google Web Toolkit (Java). Однако обе библиотеки не предоставляют HTML-версии, для ситуаций, когда JavaScript недоступен.
К числодробилкам часто хочется иметь веб-интерфейс. Написать его можно на том же языке, что и саму числодробилку (часто это как раз C/C++/Java). Причем задача генерации HTML перекладывается с разработчика на библиотеку: написание веб-интерфейса напоминает написание обычного графического приложения, например на Qt.
Но при стандартном использовании можно обойтись без использования HTML, CSS и JavaScript.
Кстати, в галерее виджетов не представлены некоторые виджеты библиотеки, например, WGLWidget для работы с WebGL.