Hello

I read Dave's Publish-subscribe walkthrough in the bath just now, and
thought I'd put down a few initial thoughts to get the ball rolling.

Please don't hesitate to shoot me down - beneath this thin-skinned
and soft exterior lies an equally soft centre that is, however, used
to being shot at :-)

First, a few premises:

1) the 'proxy' mechanism that is described in the "The connection to
IM" section is a nice one to go for at this stage, as it requires
less change than would otherwise be necessary in a 'full-blown'
conversion (which wouldn't be appropriate)

2) the main gain from taking a direction like this is that the firewall/
NAT problems fall away. Dave mentioned something about a(n up to) 30
seconds delay with current mechanisms, but I'm not sure where this
delay lies yet (I've only looked briefly at Radio since yesterday). Is
this something to solve here too?

3) for want of anything better, it may be worthwhile to go roughly in
the direction as described in the Jabber pubsub proposal ('JEP' -
Jabber Enhancement Proposal) recently submitted [1] (There's also some
slightly related info here [2] if you're interested).

Perhaps it would be appropriate to start with what the desktop sends
and receives, in Jabber-speak, to request the notification (as described
in step 2 of "The connection to the IM") and what the desktop receives
when a notification comes in (as described in step 4). (I'm guessing,
as a newbie to Radio, that we could use Jabber.root to facilitate these
conversations?)

The SEND and RECV are from the desktop's perspective:

"I just subscribed to this resource (...please notify me of changes)":

SEND: <iq type='set' to='radio-pubsub-component' id='nr1'
from='desktop'>
<query xmlns='jabber:iq:pubsub'>
<subscribe
to='xml-rpc@...:80/RPC2/xmlStorageSystem.rssPleaseNotify'\
>
<ns>(the URL of the subscribed file)</ns>
<ns>(possibly another...)</ns>
</subscribe>
</query>
</iq>


"Ok, your notification request was successfully received and proxied"

RECV: <iq type='result' from='radio-pubsub-component' id='nr1'
to='desktop'>
<query xmlns='jabber:iq:pubsub'>
<subscribe
to='xml-rpc@...:80/RPC2/xmlStorageSystem.rssPleaseNotify'\
> [note-1]
<ns>(the URL of the subscribed file)</ns>
<ns>(possibly another...)</ns> [note-2]
</subscribe>
</query>
</iq>

[...time passes...]

"Here's a notification that something has changed"

RECV: <iq type='set' from='radio-pubsub-component' id='pub1'
to='desktop'>
<query xmlns='jabber:iq:pubsub'>
<publish
from='xml-rpc@...:80/RPC2/xmlStorageSystem.rssPleaseNotif\
y' ns='(the url of the subscribed file)'/>
[note-3]
</query>
</iq>

Notes on these packets:

[note1] According to the docu [3], the rssPleaseNotify call is
deprecated. I guess we will be using the requestNotification
call soon (I see it was added today, perhaps to remove the
nominal association with RSS?)

[note2] According to the "How subscribing flows" section of Dave's
document, you can send more than one URL, as the 5th parm
is a list. Does this happen in practice?

[note3] There's deliberately no <publish/> payload, as all this is
intended to be is a poke, and the salient info is in the URL,
which we're carrying around in the <ns> tag and attribute.

One observation: whereas I mentioned that we could follow the direction
of the Jabber pubsub JEP, the pubsub 'component' mentioned in that JEP
is a pure pubsub mechanism, that records subscription requests and
receives and appropriately forwards published data. Here, however, we're
talking about something slightly different, in that incoming subscribe
requests are recorded but also forwarded, proxied, as SOAP or XML-RPC
based notification requests, and published data comes in as SOAP or
XML-RPC based notifications, and are in turn passed on in Jabber packets.

I'm sorry if this is long or "stating the bleedin' obvious", but I
thought it might be useful to marshal thoughts. Perhaps the next steps
are to think about (a) how these can be managed on the desktop (with
Jabber.root - Jeremy?) and (b) what happens at the next level 'up',
i.e. at the Jabber component level.

Kind regards
DJ

[1] http://www.jabber.org/jeps/jep-0024.html
[2] http://www.pipetree.com/testwiki/PeerkatAndPubsub
[3] http://www.soapware.org/xmlStorageSystem#rssPleaseNotify