Hi all

Well, I've been hacking away at a first version of a Jabber Radio
bridge described earlier this week [1], and I've got one up and
running.

And what's more, it works! :-)

Basically, I've implemented the "Jabber pubsub bridge" block in
the diagram, and all the lines coming into and going out of it.

That means, that for this trial, the 'dangly bits' of connectivity
are where the Jabber.root programmers come in and construct, send
and receive IQ packets. So all we need to do now is make sure that
the ends of arrows 1, 4 and 7 are properly plugged into the RU
desktop. In this respect, all that we need to do using the Jabber.root
library is:

(a) be able to send (and receive responses to) IQ packets
requesting that a notify-me be set up

(b) accept notification IQ packets that come in, as a result of
a feed changing

The bridge runs as a component on the Jabber server, and performs
all the duties necessary:

(1) accept an IQ-set 'notify-me' packet, makes a call based on the
information given in the packet (the cloud info), receives the
result and relays it back to the sender of the IQ

(2) accepts RCS-initiated pings (that are made to it as a result of
previous notify-me requests) and relays them in the form of IQ
packets to the correct requester.

For those interested, I've plonked the main bit of code up for all
to see [2 & 3].

If you're a xmlstorage.com admin, you can see proof of this stuff
going through, as you'll see notify-me requests coming in, specifying
"radioJabber.resourceChanged" as the methodCall to use for a ping ;-)

Here are some tidbits from the stuff that I've just logged while testing
with my own Radio weblog #0105912 (I've 'pretty-printed' the XML bits
so it's easier to read what's going on):

(i) Sending the 'notify-me' request from desktop to bridge and getting
an ack back:

gnu:/stuff/dj/radio$ ./subscribe-set.pl
SEND: <iq id='1' to='bridge.radio.gnu.mine.nu' type='set'>
<query xmlns='radio:iq:pubsub'>
<subscribe
to='xml-rpc@...:80/RPC2/xmlStorageSystem.rssPleaseNotify'\
>
<ns>http://radio.weblogs.com/0105912/rss.xml</ns>
</subscribe>
</query>
</iq>

[the bridge, at this point, made the XML-RPC call to the RCS]

RECV: <iq id='1' to='radiodesktop1@.../ru' type='result'
from='bridge.radio.gnu.mine.nu'>
<query xmlns='radio:iq:pubsub'>
<subscribe
to='xml-rpc@...:80/RPC2/xmlStorageSystem.rssPleaseNotify'\
>
<ns>http://radio.weblogs.com/0105912/rss.xml</ns>
</subscribe>
</query>
</iq>


(ii) This is the log output from the bridge component when (i) was
executed. The 'result' in the last line signifies that we got a result,
rather than a fault, in the XML-RPC call.

gnu:/stuff/dj/radio$ tail -f bridge.log
[debug] sub.request [2]:
xml-rpc@...:80/RPC2/xmlStorageSystem.rssPleaseNotify
[debug] --> http://radio.weblogs.com/0105912/rss.xml
[debug] sub.response [2]: result

[at this stage, I publish something to my 0105912 weblog in the
normal way. The RCS then makes an XML-RPC call to the bridge, as
requested (method call radioJabber.resourceChanged :), which is
received, ack'd, and translated into an IQ packet for the Jabber
ping.]

(iii) This is the output of a little script I'm running which
simulates the RU desktop listening for incoming Jabber packets,
and you can see it's a ping for 0105912:

RECV: <iq to='radiodesktop1@.../ru' from='radio.bridge'
type='set'>
<query xmlns='radio:iq:pubsub'>
<publish ns='http://radio.weblogs.com/0105912/rss.xml'
from='64.75.32.138'/>
</query>
</iq>

(64.75.32.138 is radio.xmlstoragesystem.com)


(iv) This is the log output from the bridge component when (iii)
happened.

[debug] pub.ping from 64.75.32.138 for radiodesktop1@.../ru
[debug] --> http://radio.weblogs.com/0105912/rss.xml


Notes
-----
There is a fair amount of error checking in the code (i.e. checking to
make sure the calls are valid, etc, but it's probably still breakable
at this point.

I'm specifying the Jabber ID (JID) (of the requesting desktop) as part
of the XML-RPC path, for the RCS to specify in its ping-call, so that
when a ping comes it, it's also innocently carrying the JID of the
intended recipient. That means I can keep the bridge stateless.

We can discuss what form these packets take - perhaps we want to
make the pings inside <message/>s, with an <x/> extension, for example.

You can play with this bridge too - it's running on my Jabber server on
the 'net, and I can supply (to this list) the test-scripts I used to send
and receive the IQ packets. But I'll do that in another mail.

Anyway, I think that's enough typing for now.

Questions, comments, etc etc always welcome

DJ


[1] http://www.pipetree.com/testwiki/RadioJabber
[2] http://www.pipetree.com/~dj/RadioBridge.pm
[2] http://www.pipetree.com/~dj/bridge.pl