[JDEV] priority question

Sun Apr 21 22:59:27 CDT 2002

In that case, what's to prevent a Jabber client from initiating several
connections to the server with JIDs like:
<someone at somesite/withresource;accept=text> or
<someone at somesite/anotherresource;accept=application/video>
with the current resource system?

What I'm getting at is that any resource system can be abused rather
easily, but there's no rule that says one must abuse everything abusable.

 - Dave

BTW - It's worth noting that naming resources with capabilities is not
a requirement of a pure pub/sub routing system.  It's just that if all
clients that have a particular capability subscribe to a designated
channel, somebody who wishes to videoconference with you can simply
send the videoconferencing invitation to you at yourserver/videoconf -
a rather easy JID to form JIT.  Don't feel limited by that convention,
though: I can setup a whole bunch of autoresponse bots to subscribe to
me at myserver/autoreply, where each of them will answer a different type of
query.  The current Jabber resource system has _no way_ of accomplishing
the same effect without manually configuring Jabber Message Rules in a
slightly tricky manner (which may not even be obvious to half the devs
here) - or without using a proxy (which is a very unclean approach,
although I must admit that I'm working on a rather ambitious project
that will essentially be that very unclean proxy ... before you go ahead
and thwap me, please allow me to point out that proxying Jabber per se
was _not_ the original intent of my project, and is still not exactly
the primary purpose of the project: I want to provide a stable "client"
that UIs can connect to in order to provide IM functionality to end users
- I'm trying to seperate the IM functionality from the user interface,
because I can then access the same Jabber session from my GUI client in X,
as well as my curses client from the shell, and the CLI client that I'm
working with from an emacs window ... it also means I can telnet to my
machine and get all the messages I've received when I open a Jabber client
remotely, so I don't have to run all my programs from screen sessions
... finally, it allows me to create a high-powered logging system which
isn't tied down to any particular UI, and which gives me the ultimate
in flexibility - to store the data in an offsite database, for instance).

Jean-Louis Seguineau /EXC/TEC wrote:
> 
> 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
> > >
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 