Hi all.
I have wanted to push RC-messages via XMPP for a long time. I have now a working demo on the toolserver: join enwiki@conference.jabber.toolserver.org with any jabber client to see the human readable part.
The demo works by polling the API, for production use, http://www.mediawiki.org/wiki/Extension:XMLRC should be enabled on the live sites.
The architecture is similar to the one used for the IRC channels: MediaWiki emits UDP packets (in the case of XMLRC, containing XML - the same <rc> tags you would get from the API). The packets are received by a standalong bridge process (written in python) that multiplexes the messages into the appropriat channels (XMPP MUC rooms, in my case). Details can be found on the extension page.
I have also written a small client lib that provides convenient access to the RC properties that are enclosed in the XMPP message. See the extension page for links.
So, what do you think, what would it take to get this live?
-- daniel
PS: relevant tracking bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=17450
Addendum:
I have put some more details about the idea and the demo setup at http://meta.wikimedia.org/wiki/Recentchanges_via_XMPP.
-- daniel
Daniel Kinzler wrote:
I have put some more details about the idea and the demo setup at http://meta.wikimedia.org/wiki/Recentchanges_via_XMPP.
I put some comments and questions on the talk page.[1] I figured that was as good a place as any.
MZMcBride
[1] http://meta.wikimedia.org/wiki/Talk:Recentchanges_via_XMPP
MZMcBride schrieb:
I put some comments and questions on the talk page.[1] I figured that was as good a place as any.
MZMcBride
[1] http://meta.wikimedia.org/wiki/Talk:Recentchanges_via_XMPP
I have replied in detail there. Here's a quick overview:
1) better convention for channel names? that's a configuration issue. 2) extra channels that include full text, diffs, etc? UDP is a limiting factor here. Alternative transport from PHP to the bridge process? 3) why include a human readable message? because i'm (ab)using a chat protocol, and people could find it nice to eyeball it. However, support for pubsub is planned, for pure data distribution. 4) what doies the output look like for a page move? The human readable part looks like it does on IRC now, the XML just like what you get from the API (when including loginfo in rcprops).
-- daniel
2010/8/19 Daniel Kinzler daniel@brightbyte.de:
- extra channels that include full text, diffs, etc? UDP is a limiting factor
here. Alternative transport from PHP to the bridge process?
Named pipes? Of course only if PHP can keep named pipe open in persistent mode. I'm not sure if this is easy or even possible at all ;)
AJF/WarX
Artur Fijałkowski schrieb:
2010/8/19 Daniel Kinzler daniel@brightbyte.de:
- extra channels that include full text, diffs, etc? UDP is a limiting factor
here. Alternative transport from PHP to the bridge process?
Named pipes? Of course only if PHP can keep named pipe open in persistent mode. I'm not sure if this is easy or even possible at all ;)
Never done much with these, but woudn't they get confused if multiple php processes accessed a named pipe at once? also, can a named pipe be connected to a tcp stream? Hm, I guess the letter could simply by done with cat my.pipe | socat tcp:...
Otoh, I don't think opening the pipe for every edit (not request!) would be prohibitively expensive. Might be a possibility. Actually, XMLRC already supports writing to a file, so no change to the extension would be needed at all.
-- daniel
wikitech-l@lists.wikimedia.org