[Council] VOTE[JEP-22]: -1

Peter Saint-Andre stpeter at jabber.org
Sat Apr 20 12:55:26 CDT 2002


Hmm, and actually the examples of cancelling a composing event are
inconsistent (Example 3 vs. Example 8), and Example 9 contains an error.
I'll fix these minor problems. I agree that the cancellation of the
composing event is rather implicit. Any suggestions on fixing it?

As to your main point, it would be cleaner, I think, if the ID were an
attribute and not an element (that would be consistent with our usage
throughout the Jabber protocols). Maybe we would have the following
events:

<event name='offline' id=''/>
<event name='delivered' id=''/>
<event name='displayed' id=''/>
<event name='composing' id=''/>
<event name='cancelled' id=''/>  // or 'stopped'?

I think "cancelled" might be ambiguous (I could see someone thinking that
delivery of the message was cancelled), but I can live with that, though I
might prefer something like "stopped".

Peter

--
Peter Saint-Andre
email+jabber: stpeter at jabber.org
weblog: http://www.saint-andre.com/blog/

On Sat, 20 Apr 2002, Dave Smith wrote:

> Ok...a few questions...
> 
> I like the overall concept. I would like to know why "events" are encoded in
> the element name. It would be much more flexible to have something like:
> 
> <x xmlns='jabber:x:event'>
>   <event name='delivered' id='M_22'/>
> </x>
> 
> That would allow for new (non-IM) event types to be added without requiring
> schema changes. 
> 
> I'm also a bit hesitant about having cancellation of events be so implicit.
> However, that's not what's incurring the -1 vote; I just want a good
> explanation of why it's desirable to hard-code event names into element
> names.
> 
> Diz
> 
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council
> 




More information about the Council mailing list