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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
