-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/26/09 6:03 PM, Florian Zeitz wrote: > Peter Saint-Andre wrote: >> Today in the xmpp:[email protected] room we had a bikeshed >> discussion about the various transitions in Chat State Notifications >> (XEP-0085)... > >> http://logs.jabber.org/[email protected]/2009-08-26.html#15:12:36 > > One quick note about this: Some people have mentioned during the > discussion they find this whole XEP pointless
Really? I have not heard that. It is quite widely implemented. > and calling this a > bikeshed discussion has a similar impact. Quite possibly. In fact, nothing in the spec right now forbids any state transition, so I think that the discussion is a bit of a time-waster. However, I've made some proposed text clarifications to the spec anyway. > I think it implies that this > is not really worth discussing, which automatically degrades any answer > to the question, which could probably be seen as an insult to somebody > who does care, or even who bothers to join the discussion. > That said I personally don't care that much either, the following is > just to put another point of view out there. Thanks for your feedback. >> I suggest that the following are the most common/sensible transitions: > >> o (start) >> | >> | >> INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED >> | | >> | | >> +---<---<---<---<---<---<---<---<---<---+ > >> Someone suggested that you might want to do things like go from >> <inactive/> to <paused/> if a user returns to a chat session interface >> containing an unfinished message. I have no deep objection to such a >> transition, though it strikes me as a bit odd. My reasoning is that the >> <active/>, <inactive/>, and <gone/> states refer to the overall chat >> session interface whereas the <composing/> and <paused/> states refer to >> the message input interface (and are in some sense a subset of >> <active/>, so that you would go from <paused/> to <inactive/> but from >> there back to <active/> and then <composing/>). > > I would return to <paused/> for the same reason. <paused/> means someone > has been composing and is active (both intentionally without </>), > which to me is obviously the case if the message input interface is not > empty. I must say this feels quite unnatural to me, but if an implementation would like to proceed that way then I don't think the spec should forbid that (which is currently doesn't, but my proposed text changes make that even clearer). >> As I said this is painting the bikeshed and I'd just as soon leave the >> supported state transitions up to the implementation so that we don't >> need to argue about the spec all the time, but if people care about this >> I will update the spec. > > As said in the discussion I think that might be the way to go if > implementors stand by their different opinions. Yes, which is why I made the text changes I did. Given that no one involved in the original discussion (triggered by a bug report against the Gajim client) has posted in this thread, I must admit that I wonder how passionate they are about correcting the spec. However, I think the text changes I propose address their concerns. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqoYvcACgkQNL8k5A2w/vxoFACg8nn+wlV5FOaIWD4yicUZU0jh 5R4AoNVyKASsDCozR+4ANkLTnsGfAiQl =Ld+u -----END PGP SIGNATURE-----
