[standards-jig] NEW JEP: Multi-User Chat
jabber at dsutton.legend.uk.com
Mon Sep 16 20:04:53 UTC 2002
On Mon, Sep 16, 2002 at 10:03:55AM -0700, Iain Shigeoka wrote:
> On 9/14/02 9:37 AM, "Dave Smith" <dizzyd at jabber.org> wrote:
> > Why is using an error code a bad way to deal with an error? :)
> I can't speak for Ryan, but IMO, the trouble with error is that, to date, no
> one has very clearly defined what errors (code) are sent in response to what
> error conditions. So "getting an error" currently tells you something went
> wrong but leaves it to you to guess what exactly happened (unless you are an
> english speaking human that can read and understand the error message...
> Hard for computer programs, and very difficult for people who don't
> understand english).
> I would not have a problem with error IF the protocol defined all valid
> error codes for each action. We have been talking about similar efforts for
> general protocol works (using flow diagrams or something similar).
Then surely this is more an issue of not fully fleshing out the error
Error code with text explaination is always good as the computer reads
the code, and text for the user.
> > Overloading? I personally think that sending presence to a JID to
> > indicate that you are "joining" the room makes a lot of sense and maps
> > nicely to a presence-based communications system like Jabber. Why have
> > a whole seperate IQ series to "join" a room? What does it mean to join
> > a room without having any presence in that room?
> I find it confusing at times too. From an implementation standpoint,
> overloading <presence> makes it hard to determine what a particular packet
> is doing without providing access to the entire state of both the user's
> session and the server's resources. This can hurt modularity.
Tbh, the best idea i've seen so far is a hybrid of existing methods.
The client sends an initial presence to the room to show your interest. You
don't include a nick, to show you wish to use nick negotiation. The
client then sends an IQ Get, to find out the room parameters, then sends
an IQ Set to send the requested details. The component, if happy, then
sends the presence packets for each person to the client logged on, so
you have the true roster and presences.
> It also makes it hard to point to any particular packet or group of packets
> and say, "that's groupchat". Kind of silly but it really helps when trying
> to explain things to others.
I guess it boils down to whether you consider presence a segmented
thing, or just a generic statement of 'this is my presence'
> On the other hand, reusing the packets does have a certain elegance... Sort
> of the same argument as RISC vs CISC I suppose. On this debate though, I
> think I am more on the side of separating protocols by using a separate
> packet type or namespace.
> >> It would be nicer to have a cleanly designed protocol to do everything
> >> all contained within one namespace.
> > I think the point of this work is to maintain as much simplicity (and
> > backwards compatbility) as possible (i.e. GC 1.0) while providing a
> > clean and modular extension for doing advanced multi-user chat
> > functions.
> Agreed. It's great for that. I think in the future, it would be nice to
> break groupchat out from normal packet traffic (by namespace, by new root
> packet type, or something). For that, we'd need a new "protocol".
Keep groupchat as a simple multiuser communication protocol, and have
advanced features in a properly designed protocol.
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
More information about the Standards