Comments 9
Для этой же цели есть, например, программа «WebSite-Watcher» (http://www.aignes.com/index.htm), которая обходится без вмешательства в работу сервера. Чем Ваша технология лучше?
Как минимум, у «моей технологии» есть огромная экономия трафика. Ведь вам не придётся постоянно делать запросы к веб-серверу по поводу состояния ресурса. Вы получите информацию об изменении сразу же, как только кто-то на этот ресурс «наткнётся».
Технология типа указанной вами поэтому и получила распространение, что не требует внедрения в Веб-сервер. Я это понимаю и знаю насколько сложно «уговорить» весь интернет поставить на веб-сервер ещё «какие-то сенсоры». Однако, я думаю, что на некотором количестве веб-серверов организовать внедрение сенсоров вполне можно и это обоснованно. Вот и хотелось бы услышать идеи-подсказки, мнения… кому может всё это пригодиться и при каких условиях?
Технология типа указанной вами поэтому и получила распространение, что не требует внедрения в Веб-сервер. Я это понимаю и знаю насколько сложно «уговорить» весь интернет поставить на веб-сервер ещё «какие-то сенсоры». Однако, я думаю, что на некотором количестве веб-серверов организовать внедрение сенсоров вполне можно и это обоснованно. Вот и хотелось бы услышать идеи-подсказки, мнения… кому может всё это пригодиться и при каких условиях?
1. брать md5 (или любой другой хеш) от контента для создания пары идентифицирующей сущностью будет сильно тяжело для веб сервера(это же будет происходить при каждом запросу пользователем страницы?). Поэтому лучше придумать механизм нотификации при создании контента (и ввести его поддержку на уровне http серверов (в случае если появляется новый файл) или CMS (при создании новой страницы)).
Ваш вариант требует значительного увеличения мощностей веб серверов, а мой модификации кучи софта. Мне они оба кажутся не реализуемыми.
2. Сервер на который отправляются сигналы. Тут нужно делать распределенную систему сбора информации о изменившихся документах которые между собой будут обмениваться коллекциями изменений (один сервер не сможет обработать информацию о всех изменениях в контексте интернета). В итоге получится что то на подобие DNS только с большим количеством информации и частотой её изменения. Создание такой системы требует больших усилий и материальных затрат.
Ваш вариант требует значительного увеличения мощностей веб серверов, а мой модификации кучи софта. Мне они оба кажутся не реализуемыми.
2. Сервер на который отправляются сигналы. Тут нужно делать распределенную систему сбора информации о изменившихся документах которые между собой будут обмениваться коллекциями изменений (один сервер не сможет обработать информацию о всех изменениях в контексте интернета). В итоге получится что то на подобие DNS только с большим количеством информации и частотой её изменения. Создание такой системы требует больших усилий и материальных затрат.
1. всё верно. Серверу будет туго. Но снова же, есть возможность ограничить множество страниц «под наблюдением». Да использовать хоть тот же robots.txt. Ну и можно добавить опциональную предварительную проверку длинны ответа прежде чем считать md5. C модификацией публикующего софта заметно всё сложнее…
2. Да, когда я готовил диссер я в голове помнил, что есть инфраструктура DNS серверов и можно было бы создать нечто подобное. Согласен, что нужны усилия и средства. Однако, мне думается, что вполне можно было бы найти средства — достаточно посчитать деньги в которые обходится трафик роботов гугла «в мире» или яндекса «у нас». Другой вопрос, что договорится будет сложно, ибо зависеть никто ни от кого не захочет. Да и делиться информацией скорее всего тоже не очень хочется
:(
2. Да, когда я готовил диссер я в голове помнил, что есть инфраструктура DNS серверов и можно было бы создать нечто подобное. Согласен, что нужны усилия и средства. Однако, мне думается, что вполне можно было бы найти средства — достаточно посчитать деньги в которые обходится трафик роботов гугла «в мире» или яндекса «у нас». Другой вопрос, что договорится будет сложно, ибо зависеть никто ни от кого не захочет. Да и делиться информацией скорее всего тоже не очень хочется
:(
Идея могла быть актуальна и реализуема несколько лет назад. В настоящее время она уже неоднократно и по разному реализована в той или иной степени (RSS и другого рода XML-агрегаторы) или попросту невозможна, если рассматривать ее в рамках одного конкретного веб-сайта, построенного на базе CMS, т.к. в настоящее каждая отдельная страница может включать в себя множество элементов с различным периодом обновления (например, на хабре рейтинг может обновляться несколько раз в секунду).
Да, раньше было легче внедрить. Сейчас наворотили столько, что уж жалко выбрасывать.
Против частого изменения отдельных элементов страницы, очевидно пришлось бы собирать статистику «эффективных изменений» и на её основе уже принимать решение о посылке уведомления публичному серверу.
Против частого изменения отдельных элементов страницы, очевидно пришлось бы собирать статистику «эффективных изменений» и на её основе уже принимать решение о посылке уведомления публичному серверу.
Единственный вариант, как это можно реализовать — использовать XML максимально в концепции Semantic Web:
1. делать страницу изначально состоящей из смысловых блоков, каждый из которых будет иметь четкое семантическое описание, в том числе, и время обновления
2. сборщик страниц должен анализировать для каждой страницы устаревшие блоки
3. сервер должен передавать клиенту только изменившиеся блоки.
Такой подход сейчас используется во многих продуктах Google. В частности, тот же Gmail «вися» в браузере подгружает только изменения… хотя, здесь нужно оговорится: судя по логам, которые мне приходят с нашего прокси-сервера, «AJAX-переписка» страницы с сервером по трафику просто сумашедшая. Сейчас, после последнего обновления GMail стало лучше, однако, все-равно грузиться очень много данных.
Вообще, принцип частичного обновления данных давно уже обсуждается и на сегодняшний день самый популярный способ решения — агентный подход. Самый простой пример — ася (Кстати, по сравнению c GTalk ася потребляет в разы меньше трафика. По этой причине, при всей моей любви к GTalk пришлось от него отказаться в пользу QIP)
1. делать страницу изначально состоящей из смысловых блоков, каждый из которых будет иметь четкое семантическое описание, в том числе, и время обновления
2. сборщик страниц должен анализировать для каждой страницы устаревшие блоки
3. сервер должен передавать клиенту только изменившиеся блоки.
Такой подход сейчас используется во многих продуктах Google. В частности, тот же Gmail «вися» в браузере подгружает только изменения… хотя, здесь нужно оговорится: судя по логам, которые мне приходят с нашего прокси-сервера, «AJAX-переписка» страницы с сервером по трафику просто сумашедшая. Сейчас, после последнего обновления GMail стало лучше, однако, все-равно грузиться очень много данных.
Вообще, принцип частичного обновления данных давно уже обсуждается и на сегодняшний день самый популярный способ решения — агентный подход. Самый простой пример — ася (Кстати, по сравнению c GTalk ася потребляет в разы меньше трафика. По этой причине, при всей моей любви к GTalk пришлось от него отказаться в пользу QIP)
На сколько я понимаю, моя высказанная концепция — это далёкое будущее Интернет. Семантический Веб — тоже будет повсеместно использоваться не завтра и не послезавтра. Поэтому вариант с семантическим анализом для выявления изменённых блоков информации пригодится, ибо сенсор придётся научить интеллектуальному распознаванию изменений веб-страниц.
Конкретно по 3-му пункту скажу, что это вряд ли вообще нужно. Ибо клиент сам должен решать, что ему делать с уведомлением об изменениях.
Конкретно по 3-му пункту скажу, что это вряд ли вообще нужно. Ибо клиент сам должен решать, что ему делать с уведомлением об изменениях.
Sign up to leave a comment.
Сенсоры для мониторинга контента на Веб-сервере