Talk:Recentchanges via XMPP

From Meta, a Wikimedia project coordination wiki

Feature requests and questions[edit]

I can file any of this in Bugzilla as necessary, just let me know.

  1. I think consistency in channel names is crucial and should be enforced with extreme rigidity. Currently the IRC feed uses a horrible combination of channel names (some are the domain with ".org" stripped, some are complete special cases like "wikimediafoundation.org" or "liquidthreads-labs.wikimedia", some are the product of history or error like "wikimania2010.wikipedia" and "outreach.wikipedia", etc.). This makes it a complete headache to deal with. It doesn't particularly matter which channel name format is used as long as it's sane and consistent.
  2. There was a discussion at some point about setting up two separate feeds, one for full page text+revision meta-data and one for just meta-data. I think there may be a bug filed about this already. Is this part of your considerations/architecture? Should it be? I think the idea was to set up two different channels for each wiki in order to allow easy pushing of page text for those who want it, without burdening the extra bandwidth on those who don't.
  3. I'm not sure I understand the purpose of the <body> element. It seems like a preformatted combination of the parts of the <rc> element. What's the value?
  4. Can you paste some example output from the result of something like a page being moved?

Thanks. :-) --MZMcBride 21:02, 18 August 2010 (UTC)[reply]

Thanks for your comments. So, here goes:
@1: I agree, but this is a matter of configuration. The software as it is doesn't invent any channel names, they are all configured explicitely. Creating new channels automatically on demand could be done, but needs some more thought.
@2: Providing full text with the RC event, and/or a full unified diff, or link-diffs (please!), would all be quite nice, but won't work with the current architecture, because the size of UDP packets is limited (currently, I use a limit of 8KB). We would need a different mode of transport from the php process to the XMPP bridge. Something fast and non-blocking, yet capable of transmitting long chunks of text. Any ideas?
@3: The body element contains the human readable part of the message. There are two reasons to include it:
  1. to make XMLRC behave similarly to the current IRC channels, simply so people can check out what's happening by using a standard chat client and eyeballing the channel.
  2. I'm abusing a chat protocol (Jabber/MUC) for data distribution - I'm not sure, but I think the body tag is mandatory in these messages. If we used an XMPP extension that is tailored for data distribution, such as PubSub [1], we would not need it (I'm not even sure it would be possible to include a human readable body this way). PubSub support is definitly on the todo list for XMLRC.
@4 The human readable output for a page move looks like this: [[Special:Log/move]] move http://en.wikipedia.org/w/index.php?page=Talk%3ARoberts+Syndrome%2FGA1&title=Special%3ALog%2Fmove * Wouterstomp * move subpage as well. The full XMPP stanza:
<message xmlns="jabber:client" to="daniel@jabber.toolserver.org/899f047d" type="groupchat" id="277658" from="enwiki@conference.jabber.toolserver.org/xmlrc">
  <body>[[Special:Log/move]] move http://en.wikipedia.org/w/index.php?page=Talk%3ARoberts+Syndrome%2FGA1&amp;title=Special%3ALog%2Fmove * Wouterstomp *  move subpage as well</body>
  <rc comment="move subpage as well" newlen="0" rcid="390853022" pageid="28427231" title="Talk:Roberts Syndrome/GA1" timestamp="2010-08-19T09:14:59Z" redirect="" wikiid="enwiki" revid="0" logid="31054175" logtype="move" old_revid="0" user="Wouterstomp" logaction="move" ns="1" type="log" oldlen="0">
    <move new_title="Talk:Roberts syndrome/GA1" new_ns="1" />
    <tags />
</rc>
</message>
...note the <move> tag with all the extra info you may want. The <rc> tag ios *exactly* the one you would get from the API. If the API is updated to include more info, XMLRC will profit from it automatically, since it simply reuses the API's code for generating XML for RC events.
HTH -- Daniel Kinzler (WMDE) 09:22, 19 August 2010 (UTC)[reply]

This might attract some attention on the feature request. Nemo 10:05, 19 February 2012 (UTC)[reply]