[JDEV] priority question

[Dave]

What I call "the resource system" is the set of rules deciding which
client connection to send a message to.  I propose not having resources
identify client connections, but rather identify channels that people can
publish on (and/or subscribe to).  It would then be the job of each client
upon connection to subscribe to whatever channels it wants.  Obviously,
it'd make sense (for backward compatibility, at least) to subscribe to
some sort of descriptive resource (dave at dave.tj/Gabber, for instance)
automatically so clients that like to reply to the actual resource
initiating the conversation (as opposed to the base JID) don't get left
in the cold, and so that you can always send a message to any of your own
clients directly.  However, each capability can have a default resource
assigned to it, so any client capable of videoconferencing and logging in
as myself, for instance, can subscribe to the dave at dave.tj/videoconf JID.
Now, if somebody sends me a videoconferencing invitation, it'll get sent
to all my videoconferencing-capable Jabber clients.  If I don't want one
particular client to get all the text messages that come my way, I can
tell it to unsubscribe itself from the dave at dave.tj/textmessage JID.
I can create a dave at dave.tj/htmlmessage JID (i.e., an htmlmessage
resource), and have a text-only Jabber client coupled to a Web browser
subscribed to that channel, so people can send me HTML messages.
I can have a stupid Jabber program that simply cats everything >
logfile subscribe to _all_ my resources.  Obviously, I can also add
a dave at dave.tj/email resource which will cat everything > mail dave,
and other neat stuff of the sort ;-)

Now, if we add a special meaning to the outgoing resource so that anything
sent from any of your client connections is published on that resource
automatically, then you can have all sorts of cool processors subscribing
to that resource and doing neat stuff inline with outgoing messages.
(A more generalized version of the above would be to have a list of
resources that every outgoing message gets forwarded to sequentially
(taking the result returned by each filter), before finally being sent
out on the Jabber network.  I think that last part may be a little on
the overkill side for any normal purposes, though.)

Hope that clarified everything,
Dave Cohen <dave at dave.tj>


Peter Saint-Andre wrote:
> 
> To my mind, what you call "the resource system" is an addressing scheme.
> Are you proposing that we throw out the resource part of a Jabber ID?
> 
> Just curious. :)
> 
> Peter
> 
> --
> Peter Saint-Andre
> email+jabber: stpeter at jabber.org
> weblog: http://www.saint-andre.com/blog/
> 
> On Wed, 17 Apr 2002, Dave wrote:
> 
> > Maybe we should consider tossing the "resource" system, and replacing it with a pub/sub architecture; that'll allow individual users to define the answers to all the questions below, rather than having an increasingly complex protocol dictate answers that may be somewhat less than perfectly apparent even to people as intelligent and well-versed in Jabber as Mr. Waite (obviously much less apparent to your average Joe using Jabber as a simple IM system - myself, for instance).
> > 
> > To the best of my knowledge, there's no requirement for JNG to be compatible with the current Jabber protocol, so we should be able to pull off the switch at this point.  In the long run, I believe we'll find that the work to overhaul the whole basic Jabber protocol will have been well worthwhile.  (In fact, I'd be willing to rewrite any part of the OSS Jabber server that nobody else wants to - I have a fair amount of free time that I spend coding my Jabber proxy server (and reading most of the Jabber and IPv6-related mailing lists) that I wouldn't mind reallocating to work on rewriting parts of jabberd, if that's what it takes to get the Jabber protocol refocused on a fundamental architecture that'll give us a tremendous amount of power in the messaging and presence management worlds, as well as a concrete base on which media delivery systems can be built with relative ease.)
> > 
> > Dave Cohen <dave at dave.tj>
> > 
> > 
> > David Waite wrote:
> > > 
> > > Here's a couple of the questions I'm wondering
> > > 
> > > - What is the behavior when a lower-priority resource changes presence?
> > > - What is the behavior when a lower-priority resource changes to the 
> > > highest priority, or vice-versa? (keep in mind that some clients change 
> > > priority when they go auto-away, and any presence change within a 
> > > priority level makes that client have the highest priority)
> > > - What is the behavior when the highest-priority resource logs out? (I'm 
> > > assuming a lower-priority resource is ignored)
> > > - How should invisible mode interact, in both the case where the remote 
> > > system does and does not support invisible mode?
> > > - What is the correct behavior when a message is sent from a resource 
> > > which is not the highest priority? Do responses get sent to a different 
> > > client (and how would that happen)?
> > > 
> > > -David Waite
> > > 
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > > 
> > 
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> > 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>