I think we need to be clearer about what the goal is here, as is I think we are all taking our personal idea of what we want to do with a feed and applying that to this implementation. Personally I have been working on an external watchlist service that i would love to hook up to a feed, but without any guarantees of receiving every single event my particular use case is better off continuously scanning the xml feeds of 800 wikis. I'm certain other people are thinking of completely different things as well.
Erik B.
On Mon, May 5, 2014 at 2:29 AM, Petr Bena benapetr@gmail.com wrote:
Given the current specifications I can only support this change as long as current IRC feed is preserved as IRC is IMHO, as much as evil it looks, more suitable for this than WebSockets.
I am not saying that IRC is suitable for this and I know that people really wanted to get rid of it or replace it with something better, but I just can't see how is this better.
On Mon, May 5, 2014 at 10:37 AM, Daniel Kinzler daniel@brightbyte.de wrote:
Am 05.05.2014 07:20, schrieb Jeremy Baron:
On May 4, 2014 10:24 PM, "Ori Livneh" ori@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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l