Re: [JDEV] Error messages (was: jabber.transport dropping connection..)

[Jeremie <jeremie@jabber.org>]

> 	I noticed that when an XML processing error occurs, jabber.transport
> promptly drops connection..  I'm wondering if this is how it should be
> handled, versus perhaps creating a new entry in our little protocol scheme.
> 
> <error>
>   <type>Parse</type>
>   <description>There was an error parsing your XML</description>
>   <severity>Fatal</severity>
> </error>
> 
> 	This would also allow for other errors that need to be passed back to the
> client to be, such as user login errors:
> 
> <error>
>   <type>Authentication<type>
>   <description>Invalid User ID/Password</description>
>   <severity>Mild</severity>
> </error>
> 
> 	Comments?  Suggestions?

Right now the approach is to actually send a <message/> with
<ext>error</ext>.  I've gone back and forth with myself about this a few
times, and am really sitting on the fence.

On one hand, I like having errors be special messages that clients can
*optionally* intercept, or just deliver them.  This is just one less thing
that a client would be _required_ to deal with and one less, and one less
thing the server and transports have to handle.  Basically, if you
consider "messages" to be your primary communication channel(like email)
then errors would just be delivered via that channel.

On the other hand, it's really tempting to add to the protocol and create
a nice clean way of communicating errors.

I think I'm still of the attitude that if we can utilize the existing
protocol to do this *and* add the feature of allowing clients to be
simplier if they want to be, than using messages to communicate errors is
better.

It's difficult to strike a good balance between protocol bloat and
overloading the existing structure.  Currently, I see things breaking down
thusly:

	One time value communications: <messages/>
	Background "status" communications: <status/>
	Client only sesion communications: <roster/>
	Global static information communications <query/>  (this is new)

Errors definately fall into the first category :)


On the first subject, just disconnecting when XML errors happen:  yes,
it's probably not the nicest thing to do... It shouldn't happen in the
"real world" often, but I'll have it at least send an error of some type
before it disconnects. 


Jer