У нас в Яндексе вчера был Бретт Слаткин и мы тёплой компанией инженеров общались про его с Брэдом Фицпатриком детище — PubSubHubbub.

Кто не знает, что такое PubSubHubbub — сходите на страницу проекта, там очень понятная презенташка, лучше и короче не расскажешь. Вещь очень перспективная, как по мне. А после общения с Бреттом я воодушевился технологией ещё больше, потому что ребята придумывают её из очень правильных предпосылок. Он подчеркнул, что простота и практичность ценятся больше теоретической чистоты, и для них пока главное — решить конкретную задачу быстрого обновления фидов, заменив периодический poll на более эффективный push.

Изюминка в том, что этот push отличается от всех предыдущих fail'ов как раз тем, что делается инженерами, и архитектура у него соответствующая (HTTP, слабая связность, отсутствие необходимости в дремучих тулзах).

Вот несколько лично мне запомнившихся хайлайтов из разговора:

В практическом плане я, кажется, воодушевился реализовать на sm.org персональный хаб для блога (как руки дойдут™). Будем ли мы что-то делать в рамках Яндекса, пока не знаю. Это всё пока требует внутреннего технического евангелизма. Но мне очень хочется :-).

Комментарии: 21 (feed)

  1. Leonya

    Да, было здорово, давно не слышал столь внятных tech talk'ов. Думаю, выступление на GDD перед тысячной аудиторией было не таким клевым :)

    Насчет friendfeed - ну вряд ли они за день это сделали, client side там не вполне тривиальный.

  2. wiz

    Думаю, выступление на GDD перед тысячной аудиторией было не таким клевым

    Тысячной аудитории в том зальчике не поместилось банально. но клёвости выступления это не отменило.

    client side там не вполне тривиальный.

    И клиент- и сервер- сайды тривиальнее некуда. Вся сложность ушла в хаб, это тоже один из поинтов PSHB.

    Я за вечер прикрутил к php-форуму рассылку уведомлений о постах в жабер и джанго-приложение.

  3. wiz

    А вот хаб не на appspot действительно хотелось бы иметь. Пока ничего дельного не нашёл.

  4. wiz

    Про ffeed кстати, он умеет тягать из гуглеридера shared items, а ридер поддерживает PSHB. В результате пост в вашей ленте появляется быстрее, чем вы страницу переключите, после нажатия "share". И это реально круто.

  5. Ivan Sagalaev

    И клиент- и сервер- сайды тривиальнее некуда. Вся сложность ушла в хаб, это тоже один из поинтов PSHB.

    Под клиентской частью friendfeed'а имеется в виду не то, что он умеет апдейты от хаба принимать, а что его HTML'ная страница держит long-poll соединение со своим сервером и тоже этот апдейт получает. Это уже к самому PSHB не относится.

  6. wiz

    А этого разве до PSHB небыло?

  7. Deepwalker

    Как я понимаю это только для чтения новостных лент, но для них никогда и не использовались технологии обмена сообщениями! Весьма различные задачи в данном контексте получаются.

    Но вообще понравилось, если не сильно критична небольшая задержка в обновлениях, то реализация протокола во многом проще всяких amqp, в основном из-за развитых средств для работы с HTTP.

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

    Тут я на самом деле увидел потенциал технологии за пределами RSS и Atom, но для этого видимо придется сделать свой хаб с другой логикой. Опять же - подтверждение подписки для механизма общей шины нечто лишнее - удобнее сделать аутентификацию.

    Заметьте - не я начал сравнивать с монстроидными amqp и тп : )

    PS Вот это прогресс - из-за косого плагина в процессе написания комментария броузер пришлось убить, но текст не потерялся - ave Mozilla :)

  8. [...] This post was mentioned on Twitter by juchkov, Shushpan4ik. Shushpan4ik said: Забавная штука - PubSubHubbub http://bit.ly/241nho [...]

  9. Vadim
        <blockquote>
    

    <p>Думаю, выступление на GDD перед тысячной аудиторией было не таким клевым :)</p> </blockquote> <p>Одна из самых интересных и, на мой взгляд, - удачных сессий на GDD (из тех, что удалось посетить).</p> <p>Client-to-Hub взаимодействие они пока не рассматривают. На этот вопрос Брет ответил, мол есть куча разных методик реализации онного на клиенте и, в связи с этим, они решили не стандартизовывать этот вид взаимодействия.</p> <blockquote> <p>Если это так, и хаб работает только с лентами, то это несколько ограничивает применение по моему - мне вообще не понятно, зачем хабу ходить за лентой после уведомления о новом контенте - просто отдать контент в уведомлении разве нельзя?</p> </blockquote> <p>Да, хаб основан на семействе протоколов RSS, т.е. работает только с "новостными лентами" (кто сказал, что там должны быть ленты и только ленты?). Почему в уведомлении не отдать? На этот вопрос Брет ответил что-то вроде следующего: есть ряд проблем, как то - необходимо убедиться в identity уведомляющего, необходимо как-то его авторизовывать, необходимо как-то убеждаться в успешной доставке сообщения и т.д. - если Вы можете решить все эти проблемы, то, с тем же успехом Вы можете запустить свой хаб - это настолько же сложная задача. Действительно, если подумать - хабов, подписанных на уведомления может быть несколько тысяч, рассылать им весь контент полностью на каждый чих - не так просто решить эту задачу...</p> <blockquote> <p>Опять же - подтверждение подписки для механизма общей шины нечто лишнее - удобнее сделать аутентификацию.</p> </blockquote> <p>Это делается для предотвращения спама/DoS эффектов на подписчика. Сделать этот процесс удобнее невозможно. Если бы и было возможным - у тех же Google Apps давно появилась бы "удобная" возможность подтверждения того, что домен действительно твой.</p> <blockquote> <p>Кому это интересно, действительно?</p> </blockquote> <ol> <li> <p>Владельцам популярных текстовых генераторов: при достаточном развитии технологии обязательно появится ready-to-deploy решение, устанавливающееся на отдельном сервере, тем самым разгружая основной сервер от раздачи обновлений.</p> </li> <li> <p>Хаб может вставлять контекстно-зависимую рекламу.</p> </li> </ol>

  10. wiz

    Это я так понял из презентации.

    Вот из презентации я тоже нифига не понял пока сам от него вживую не услышал всё это.

  11. Александр Кошелев

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

    Так это и есть проверка на легитимность контента. По сути нотификацию может послать кто угодно, но он не может внедрить посторонний контент в другую ленту, т.к. хаб сам сходит к нему на урл фида.

  12. Glader

    Я правильно понимаю, что это все для ускорения получения данных из лент и уменьшения нагрузки на сервер?

  13. astur.net.ru

    А в чём проблема с бизнес-моделью? Держат же люди джаббер-серверы не имея с них ни грамма дохода... С точки зрения бизнеса - разницы никакой.

  14. Роман Ворушин

    Тоже с удовольствием слушали доклад Бреда Слаткина на GDD. Hubbub действительно радует практичностью, красотой и смелостью.

  15. Тимур

    Я кстати понял теперь зачем нужен Твиттер :-)
    Он же как раз и является реализацией pubsub протокола :-)

  16. Ivan Sagalaev

    Проблема как раз в том, что не является: все Твиттер-клиенты периодически опрашивают сайт. И как раз Твиттер очень сильно выиграл бы от push-технологии. Проблема только в том, что pubsubhubbub подразумевает, что сервер (тот же Твиттер) может послать POST-запрос клиенту. А если клиент — это реальная консумерская машина за файрволом или мобильный телефон или что-то такое, то она в большинстве случае не открыта для внешних коннектов. И это пока нерешённая проблема.

  17. Deepwalker

    Ну long poll конечно костыль, но иначе по моему файрволы, наты и прокси не обойти. С другой стороны правильно сконструированные приложения могут держать огромное количество соединений.

    Таким образом проблемы то как бы нет, но общее впечатление от костылей всегда портится.

  18. Google user

    На GDD Brett отлично ответил на интересный вопрос. Чем оно хуже RabbitMQ? Барабанная дробь. Тем, что для AMQP нет железных балансеров. А для HTTP есть. Ещё он сказал, что RabbitMQ, возможно, лучше подойдёт внутри компании, в то время как PSHB рассчитан исключительно на внешние, интер-сервисные отношения.

    Поддержка PSHB в FriendFeed, отчасти заняла так мало времени (по-моему) потому, что он изначально задумывался как универсальный агрегатор. То есть там есть такой бизнес процесс - принятие новых фидов и PSHB стал просто очередным "плагином". Это я к тому, что прикрутить PSHB для своего уютного бложика может занять не один вечер на коленке.

    Идея о том, что какой-нибудь блогохостинг, получая новый пост, может сначала разослать апдейты всем получателям, а потом только заняться неспешным складыванием его в БД

    А как же durability? Нет, я согласен, что рассылать можно сразу. Но не надо ждать рассылки до складывания в базу. Так, мелочь.

    Я за PSHB, если чо. Тоже очень нравится.

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

  19. Google user

    Deepwalker, в HTML5 есть WebSockets, которые позволяют открыть не-HTTP конект к серверу. Там можно делать настоящий push в клиента.

  20. evilkost

    А если клиент — это реальная консумерская машина за файрволом или мобильный телефон или что-то такое, то она в большинстве случае не открыта для внешних коннектов. И это пока нерешённая проблема.

    Насколько я понял, в PSHB клиент, это некоторый другой сервис(планеты, ридеры и т.п.). А конечный пользователь уже работает с ним (а там ChromeOS своё слово скажет ).

  21. Тимур

    Все-таки Твиттер является pubsub, но немного с другой стороны: ты являешься subscriber а те кого ты фолловишь являются publishers.
    Соответственно подписываешься на нескольких паблишеров и получаешь сообщения от них проверяя лишь одно место (!) твою home ленту.

    Так что в каком-то виде это PubSub.

Добавить комментарий

Format with markdown