Техническое: Про ускорение RSS и протоколы SUP и PubSubHub

На TechCrunch почти год назад была пара интересных статей RSS is dying и Speeding up RSS.

В первой рассказывается про то как Twitter вытесняет RSS из повседневного использования, а вторая про протоколы PubSubHub и SUP.

PubSubHub — это инициатива Брэда Фицпатрика с открытой спецификаций и открытым исходным кодом http://code.google.com/p/pubsubhubbub/. Где главная идея в том создатели RSS лент регистрируют их на одном из PubSubHub сервисов и далее пингуют сервисы при обновлении своих лент, а хабы мультикастом распространяют контент по всем подписчикам. Конечно, в такой схеме нужно чтобы клиент мог принимать новые сообщения и такие клиенты появляются, их список можно посмотреть здесь — http://code.google.com/p/pubsubhubbub/wiki/SubscriberClients
Однако изменения нужны, и на сервере, и на клиенте, и необходим внешний сервис.

SUP (Simple Update Protocol) — это протокол разработанный для FriendFeed. Также с открытой спецификацией и исходным кодом доступными здесь http://code.google.com/p/simpleupdateprotocol/
Он очень просто устроен и отличается тем что никак не специфицирует работу клиентов, а описывает механизм публикации при котором в новостные ленты сайта добавляются указания на ленту SUP где с заданной периодичностью указываются те новостные ленты где произошли изменения. Тем самым, в случае если с одного ресурса извлекается более одной RSS ленты, то число обращений можно существенно ограничить. А также за счёт того что в заголовках HTTP ответов указывается текущий статус RSS ленты, то и существенно сократить число выгрузок лент.

Лично мне оба подхода в равной степени нравятся/не нравятся. На мой взгляд они вполне равновесны.
Однако они не решают другой большой и сложной задачи которая заключается в том что же делать когда вероятность что разработчики сайтов добавят поддержку одного из протоколов очень невлика. И это, в общем-то, обыденная ситуация если вспомнить что не все сайты до сих пор поддерживают технологию RSS. А если говорить про наиболее интересующую меня категорию веб-сайтов, то до 80% из них RSS не отдают.

И вот вопрос как быть в этом случае?
Свои размышления по этому поводу я собрал в виде нескольких тезисов:
1. В зависимости от характера решаемых задач подход может быть различным. Главный критерий здесь — ожидаемый интервал оперативности в получении новостной информации и это может определять стратегии сбора информации. К примеру, если новости собранные за сутки используются лишь для дайджеста
2. У подавляющего числа RSS лент есть свои «временные паттерны». Которые можно охарактеризовать как периоды времени активности в данной RSS ленте. В большинстве случаев эти временные паттерны напрямую завязаны на суточный цикл дня и ночи привязанный к источнику этих данных и недельный/календарный цикл с учётом падения активности в выходные и праздничные дни. Разумеется в случаях когда речь идёт «естественных» новостных лентах формируемых людьми, а не ботами. При выявлении характеристик этих циклов могут быть определены интервалы опроса источников информации. Это может позволить соблюсти баланс между использованием ресурсов и частотой обновления.
3. Некоторые сервера честно возвращают даты фактического обновления в «Last Modified», некоторые отдают заголовок «ETag» и чаще отдают информацию о размере страницы/ленты. При наличии этой информации её можно использовать для сокращения числа GET запросов. Правда, при этом сразу возникают другие особенности — в том необходимо убедится в том что информация в заголовках от сервера корректна. Например, несколько раз я сталкивался с тем что возвращалось неверное значение ETag, в том что «Last Modified» возвращает корректные значения также необходимо убеждаться, равно как и есть определённые риски в использовании «Content-Length» для принятия решения об обновлении или необновлении RSS ленты.

Минусы этих подходов — необходимости предварительного сбора накопления информации перед тем как выбирать правильную стратегию опроса RSS лент. И, конечно, универсальным решением это не является, в отличии от SUP’а и PubSubHub. Правда, подозреваю что до тех пор пока разработчики CMS не начнут включать поддержку одного из них в свои продукты по умолчанию, на большинстве сайтов мы их так и не увидим.