Am 05.05.2014 07:20, schrieb Jeremy Baron:
On May 4, 2014 10:24 PM, "Ori Livneh"
<ori(a)wikimedia.org> wrote:
> an implementation for a recent changes
> stream broadcast via socket.io, an abstraction layer over WebSockets that
> also provides long polling as a fallback for older browsers.
[...]
How could this work overlap with adding pubsubhubbub
support to existing
web RC feeds? (i.e. atom/rss. or for that matter even individual page
history feeds or related changes feeds)
The only pubsubhubbub bugs I see atm are
https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=38970%2C30245
There is a Pubsubhubbub implementation in the pipeline, see
<https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FPubSubHubbub>. It's
pretty simple and painless. We plan to have this deployed experimentally for
wikidata soon, but there is no reason not to roll it out globally.
This implementation uses the job queue - which in production means redis, but
it's pretty generic.
As to an RC *stream*: Pubsubhubbub is not really suitable for this, since it
requires the subscriber to run a public web server. It's really a
server-to-server protocol. I'm not too sure about web sockets for this either,
because the intended recipient is usually not a web browser. But if it works,
I'd be happy anyway, the UDP+IRC solution sucks.
Some years ago, I started to implement an XMPP based RC stream, see
<https://www.mediawiki.org/wiki/Extension:XMLRC>. Have a look and steal some
ideas :)
-- daniel