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@somesite/withresource;accept=text or someone@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 <[EMAIL PROTECTED]> > Subject: Re: [JDEV] priority question > To: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > > 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 ([EMAIL PROTECTED]/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 [EMAIL PROTECTED]/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 [EMAIL PROTECTED]/textmessage JID. > I can create a [EMAIL PROTECTED]/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 [EMAIL PROTECTED]/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 <[EMAIL PROTECTED]> > > > 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: [EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> > > > > > > > > > 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 > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > > > _______________________________________________ > > > jdev mailing list > > > [EMAIL PROTECTED] > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
