[JDEV] jabberd patch

[Matthew A. Miller]

Let me first say a few words before I disagree (-:  I'm not saying you
are "wrong" or "right".  Both you and Wes have valid and demonstrable
points, and each is "more correct" in some circumstances than in others.

With that said, I disagree that there should be a "standard and default"
option here.  If the XMPP specs would be changed/amended to describe the
possible behaviors, and the servers modified to implement this behavior,
then this can safely be left as an "exercise of the implementor".  Since
the process and expected behavior would be well-defined, the "default"
behavior is a matter of policy, not technicals.

It's up to the implementations (and their usage) to decide which policy
they apply.  For most "public servers", it sounds like the preference is
for "drop the old, keep the new".  I know from experience with
"paranoid" environments that "option #1" is unacceptable, but "option
#2" ("keep the old, drop the new") is acceptable.  There is more to
consider here than just "public Jabber servers", especially for the
"flagship" [server] implementation (IMHO).

The point here is that the XMPP standard be drafted to say that "it's
implementation specific, but here's the only possible 'output' given
these 'inputs'".  If you want the public server you use to use option
#1, lobby that administration (and development) team to support this by
default.

If it's any consolation, my guess is that [if my suggested "compromise"
were accepted] that developers of public-use, general-purpose servers
[e.g. jabberd2] would default to "option #1".


-  LW

On Wed, 2003-02-26 at 01:15, Richard Dobson wrote:
> Yea thats ok, so long as the current method is the standard and default
> option and that the second reverse option should only be used if your
> sepecific application requires it, it should not be used in ordinary client
> environments tho IMO especially ones with novice users, also the problems in
> using the second method must be highlighted and the normal first option
> being defined as the prefered option.
> 
> Richard
> 
> ----- Original Message -----
> From: "Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com>
> To: "JDEV Mailing List" <jdev at jabber.org>
> Sent: Wednesday, February 26, 2003 1:42 AM
> Subject: Re: [JDEV] jabberd patch
> 
> 
> > The more I read this thread, the more I agree with both sides...
> >
> > Is there middle ground to be had?  What if XMPP were defined in such a
> > way that if a connection/session attempted to auth as an already online
> > one, it was up to the server.  If the server decided it was allowed, it
> > sent the appropriate iq-error to the original connection (302?) along
> > with the disconnect.  If the server decided it wasn't, it sent a 409 or
> > 405 iq-error to the new connection along with the diconnect.
> >
> > Does the above sound reasonable?  If so, I'll make a point of
> > approaching the XMPP I-D authors on it.
> >
> >
> > -  LW
> >
> > On Tue, 2003-02-25 at 16:03, Wes Morgan wrote:
> > > I forgot to mention why I needed this behavior in the first place... I
> > > implemented a custom web-based chat system for a client that uses
> jabberd as
> > > its backend. However, one of the requirements for the system was that
> users
> > > could only log on once, and that if they tried to log on a second time,
> they
> > > wouldn't be allowed (unless, of course, they terminated the first
> session). I
> > > had been keeping track of this in a state database that my auth agent
> was
> > > using (it communicates with jabberd at the XDB level), but sometimes
> jabberd
> > > and this database would get out of sync with each other. So, I decided
> to
> > > just build this functionality into jabberd itself. That's why, for my
> needs,
> > > it wouldn't work to just "define the protocol" as kicking the first
> > > connection when a second one comes along. I at least need the option of
> > > changing the functionality.
> > >
> > > Wes Morgan
> > >
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > --
> >
> > Matt "linuxwolf" Miller
> > JID: linuxwolf at outer-planes.net
> > E-MAIL: linuxwolf at outer-planes.net
> >
> > - Got "JABBER"? (http://www.jabber.org/)
> >
> > _______________________________________________
> > 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
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)