[standards-jig] Pub/Sub for JNG?

Dave dave at dave.tj
Sun Apr 28 18:47:28 UTC 2002


Here's something I've been fooling around with for a while.  I know
it's not ready for a real spec yet, but I think the flexibility of my
proposal is readily apparent, and I hope you folks can help turn this into
something that can be used as the foundation for JNG.  Anyway, here goes:

First, forget everything you know about resources.  They don't exist.

Now, when we break down a JID, we have user at host/resource.  The user
and host fields should be self-explanatory, but the resource field
is not (since you've forgotten everything you know about resources).
The resource identifies the "topic" that you're publishing/subscribing to.
For instance, sending a message to dave at dave.tj/incoming will cause the
message to be delivered to my incoming queue.  My client is probably
subscribed to my incoming queue.  My logging component is also probably
subscribed to my incoming queue.

Now, my presence will generally be broadcast on the presence resource,
so anybody subscribing to dave at dave.tj/presence (presuming I OK the
subscription, of course) will receive updates concerning my presence.
Other likely "services" are the outgoing resource, which will send
anything I give it to the outside world (making it very easy for me to
write a bot to intercept my outgoing messages, do emoticon translation,
etc.), the vcard resource which broadcasts my vCard, and a generic info
service, which broadcasts anything I think people who are interested in
me should want to know.

You're not limited to these services.  A pager resource can be used to
alert me to something time-sensitive (assuming I've setup a program to
subscribe to my pager resource).  I can also set up a group chat service
by simply telling everybody to broadcast and subscribe to a random
resource - say, groupchat - since they'll all receive every message sent
to the resource.

Now that we've gone through a rough overview, I'd like to present
some issues:

Queuing:
This system would not queue anything unless the publisher wants it to.
(For instance, if I have a home-temperature resource, it may be desireable
to save the most recent message, in case somebody subscribes and wants
to know the last temperature reading.  This is even more important for
low-traffic resources - say, annualreport.  A group chat resource will
also be likely to save the most recent batch of messages, to give people
just entering a little jump start.)  In any case, if the publisher chooses
to queue the last x messages, they'll all be delivered immediately to
any new subscriber.

Waiting for subscribers to reap their mail:
This is a non-issue with the system I propose, because offline storage
is managed by a seperate component.  (Many servers may wish to link the
offline-logging component with the base server for performance reasons,
but the outline above makes a very clear distinction between the two, and
they _can_ be implemented completely seperately, if desired.)  My personal
proposal for people who are usually connected with the same client is to
leave their clients in unavailable mode, or whatever - some mode which
would continue to be online, but would broadcast unavailable over the
presence resource, so you appear to be offline (kinda like invisible,
except that your client won't bother alerting you to new messages,
since you're not home).

Presence management:
This is an area where a pub/sub back-end provides some rather nifty
possibilities.  The AIM-t can subscribe to your aim-presence resource
in order to find out how it should represent you on the AIM network;
the MSN-t can subscribe to your msn-presence resource.  Your friends
can subscribe to friends-presence.  Your family members can subscribe
to family-presence.  You can then change your presence only to some
groups of people.  Of course, since the convention will probably be
for the presence resource to denote presence, you'll want to setup an
autoreply for anybody who tries to subscribe to your presence resource,
telling him to identify himself, and that you'll tell him what resource
to subscribe to.  (I'm wondering about the possibility of a "redirect"
message?)

Mobile IM:
The mobile client can offload much of its processing to a corporate
server, or similar, by having it subscribe to the incoming resource
for the mobile client.  The corporate server can then do most of the
data munching, and return an oversimplified result to the mobile client.
It can also subscribe to the outgoing resource, allowing it to translate
the client's (oversimplified, perhaps) messages into more substantial
pieces of work.  This method allows mobile clients to take on more
of their processing/bandwidth load as they become more capable, but a
translation module can easily be placed between them and the rest of
the Jabber network.

Transports:
The same exact tactic can be employed for transports, allowing them to
offload processing-intensive tasks to a seperate system.  The general
idea here is that clients on remote networks will seem like standard
Jabber clients supporting a certain subset of the Jabber capabilities
(just like most real Jabber clients - none of which support _every_
capability).  Which capabilities are available will depend on which
capabilities the transport in question is willing to translate between
the foreign network and the Jabber network.  (A pub/sub backbone makes
it easier to break down a transport into seperate modules.  There's no
reason why some clients can't supply their own modules for translating
some stuff - emoticons happen to be a hot issue here, and file transfer
may become one, as well - while letting the standalone transport handle
other conversions.)

Okay ... now, let the flaming begin ;-)

Dave Cohen <dave at dave.tj>



More information about the Standards mailing list