I've fiddled around with this a bit:
On my Ubuntu system, I simply got a library: sudo pip install
socketio-client
Then made this Python script:
---
from socketIO_client import SocketIO, BaseNamespace
class RecentChangeNamespace(BaseNamespace):
def on_connect(self):
self.emit('subscribe', ['enwiki'])
def on_change(self, data):
print(data)
socketIO = SocketIO('rcstream.wmflabs.org') # This host seems to be sending
the same example entries at the moment, obviously we should get an actual
RC stream from it or a production host later
socketIO.define(RecentChangeNamespace, '/rc')
socketIO.wait()
---
And it prints entries to console like this (Python just prints out objects
in a way that kind of looks like JSON):
{u'comment': u'', u'wiki': u'enwiki', u'type': 0, u'title': u'Main Page',
u'timestamp': 1398993841, u'server_script_path': u'/w', u'namespace': 0,
u'server_url': u'http://en.wikipedia.beta.wmflabs.org', u'length': {u'new':
585, u'old': 580}, u'user': u'Alice', u'patrolled': True, u'bot': False,
u'id': 9, u'minor': True, u'revision': {u'new': 9, u'old': 8}}
It's so much nicer. Sorry Petr, I think this is much more suitable than the
mess that is connecting to IRC and parsing everything. I definitely want to
see this replace the IRC feed entirely (with the obvious reasonably long
deprecation period).
Alex
On 5 May 2014 10:29, Petr Bena <benap...@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 <dan...@brightbyte.de>
> wrote:
> > Am 05.05.2014 07:20, schrieb Jeremy Baron:
> >> On May 4, 2014 10:24 PM, "Ori Livneh" <o...@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
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
