[JDEV] priority question

Sun Apr 21 22:11:52 CDT 2002

IMHO it is not such a good practice to introduce a device/capability logic
directly into the actual resource. This is far too limitative, and would
leed to a fast "propriatarization" of client software.
Is there anything that forbid to add additional parameters to the JID
without breaking the base addressing scheme ? I was thinking along the line
of what can be seen in SIP/SIMPLE where the address scheme allow it. We
would be ending up with something like
someone at somesite/withresource;accept=text or
someone at somesite/anotherresource;accept=application/video

Jean-Louis Seguineau
Antepo, Inc.

----- Original Message -----
> --__--__--
>
> Message: 2
> Date: Sat, 20 Apr 2002 23:41:39 -0400 (EDT)
> From: Dave <dave at dave.tj>
> Subject: Re: [JDEV] priority question
> To: jdev at jabber.org
> Reply-To: jdev at jabber.org
>
> 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
> >