[standards-jig] Pub/Sub for JNG?

Piers Harding piers at ompa.net
Mon Apr 29 07:13:05 UTC 2002


Hi Dave,

I like a lot of what you put forward here.
Turn presence management on its head and represent it as a subset of
pubsub.

In some ways this reflects something that people were talking about last
year - a personal Jabber server.  An entity that represented your core
self, that you could hang services and clients off.

This kind of thing would help over come one of my personal issues with
jabber, in that it is not easy to "reuse" packets that are sent to a JID
 - they end up at one resource only, unless you make excessive use of
filters etc.

If you could subscribe to your own resources then you would have
enourmous flexibility in terms of what could be down with incoming data.
Multiple clients could receive the same packets and each perform
specialised tasks etc etc.


On Sun, Apr 28, 2002 at 02:47:28PM -0400, Dave wrote:
> 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>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig



More information about the Standards mailing list