[JDEV] Questions about jabber:x:events

[DJ Adams]

On Wed, Jun 26, 2002 at 05:22:33PM -0600, Sean Kirkby wrote:
> Hello,
>  
> I have a few questions I'm hoping someone can help with:
>  
> 1) Is the "id" attribute of a <message/> packet a required attribute?

Not in Jabber. 

> 2) If not, and a client receives a <message/> packet with a <x
> xmlns=jabber:x:events><composing/></x> request in it, how shoudl the
> client handle the request?  It will not have a message ID to put in the

That's a good question. Basically, it can handle it, but it will be
ineffectual, of course, as you describe below. There's nothing the
responder can do other than send the event (when appropriate) with an
empty <id/> tag. 
>  
> 3) Is the "composing" event the only event that really supports the
> notion of "canceling the event"?  In other words, does it ever make

With x:event, yes. 

> sense to try to cancel any of the other three events?  Rather than
> "canceling" a "composing" event, wouldn't it make more sense to make it
> two different events?  After all, if a user starts composing, and an
> event notification is sent, it really doesn't make sense to try to say
> "oops... actually, the user never really started composing... so cancel

Well, I guess it's a subjective decision. If I start typing something, then
for example, I close my compose window, that (for me) would be an appropriate
situation to send a cancel.

> that".  Rather, it would make more sense to have a "composing_start"
> event and a "composing_stop" event.  Am I off base here?

Not at all. It's not off base to query things. Good questions are always
welcome.

> 4) If "canceling" an event applies to more than the "composing" event
> (perhaps to future events not yet supported), does the current scheme
> for canceling events allow for this easily?  As far as I can tell, the
> event cancellation doesn't really identify an event to cancel.  Is the
> event cancelation supposed to apply only to the most recently received
> event, or is it only supposed to apply to composing events?

This is the most significant disadvantage of the x:event namespace. The
JEP (0022) was deliberately written to reflect the as-is situation. There
was some debate on this subject while it was being written, but I think
the general concensus was that any new features should be discussed
separately, and probably in a new namespace. 

HTH
dj