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?
 
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 <id/> element for a "composing" event packet.  Should it just send the event with no ID?  Or not send the event at all?  And does the answer to this question represent "conventional wisdom", "community consent", or is it part of the specification?
 
3) Is the "composing" event the only event that really supports the notion of "canceling the event"?  In other words, does it ever make 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 that".  Rather, it would make more sense to have a "composing_start" event and a "composing_stop" event.  Am I off base here?
 
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?
 
Thanks.
 
--sk!
 

Reply via email to