[JDEV] Questions about jabber:x:events
Hello, I have a few questions I'm hoping someone can help with: 1) Is the "id" attribute of a packet a required attribute? 2) If not, and a client receives a packet with a request in it, how shoudl the client handle the request? It will not have a message ID to put in the 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!
Re: [JDEV] Questions about jabber:x:events
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 packet a required attribute? Not in Jabber. > 2) If not, and a client receives a packet with a xmlns=jabber:x:events> 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 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
Re: [JDEV] Questions about jabber:x:events
On Wed, 2002-06-26 at 19:22, Sean Kirkby wrote: > Hello, > > I have a few questions I'm hoping someone can help with: > > 1) Is the "id" attribute of a packet a required attribute? Not yet at least. > > 2) If not, and a client receives a packet with a xmlns=jabber:x:events> request in it, how shoudl the > client handle the request? It will not have a message ID to put in the > 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? The element in jabber:x:event is required, so it's "conventional wisdom" or "common sense" that the id attribute would be required in this case. If the client doesn't send you an id attribute, you're free to not send them back the event. Their client is broken, so they shouldn't expect other clients to handle broken protocol. > > 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? Yes, the composing event is the only one which can be canceled. The lack of any event elements means the same as canceling the pending events... in the future it may make more sense to be able to cancel the composing event specifically, but as it currently stands, it's the only one you can cancel. > > 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? Composing. http://www.jabber.org/jeps/jep-0022.html Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
Re: [JDEV] Questions about jabber:x:events
On Wed, 2002-06-26 at 19:22, Sean Kirkby wrote: > Hello, > > I have a few questions I'm hoping someone can help with: > > 1) Is the "id" attribute of a packet a required attribute? Not yet at least. > > 2) If not, and a client receives a packet with a xmlns=jabber:x:events> request in it, how shoudl the > client handle the request? It will not have a message ID to put in the > 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? The element in jabber:x:event is required, so it's "conventional wisdom" or "common sense" that the id attribute would be required in this case. If the client doesn't send you an id attribute, you're free to not send them back the event. Their client is broken, so they shouldn't expect other clients to handle broken protocol. > > 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? Yes, the composing event is the only one which can be canceled. The lack of any event elements means the same as canceling the pending events... in the future it may make more sense to be able to cancel the composing event specifically, but as it currently stands, it's the only one you can cancel. > > 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? Composing. http://www.jabber.org/jeps/jep-0022.html Julian -- email: [EMAIL PROTECTED] jabber:[EMAIL PROTECTED] ___ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
