[Standards] Proposed XMPP Extension: Client State Indication
kurt.zeilenga at isode.com
Tue Aug 19 17:21:42 UTC 2014
On Aug 19, 2014, at 10:05 AM, Matthew Wild <mwild1 at gmail.com> wrote:
> On 19 August 2014 17:21, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
>> Tue, 19 Aug 2014 11:30:18 +0100
>> Matthew Wild <mwild1 at gmail.com> wrote:
>>> There are so many different approaches and optimisations (as you just
>>> demonstrated in your message!). I don't feel this XEP is the right
>>> place to document them, I think there is a lot of room for
>>> experimentation. I want to leave implementations up to server
>>> developers, deployments and (if the server allows it) client and user
>>> preference. If good ones are found, they can be documented in separate
>>> XEPs if necessary (and reference CSI).
>>> This XEP is just about giving the server more information about when
>>> it would be more appropriate to apply some kinds of optimisation.
>> I disagree. We need the exact finite state machine (like it's done in
>> good RFCs, see SIP transaction FSM or TCP FSM) which gives the
>> straightforward way to implement such optimizations. Otherwise I don't
>> see the XEP is useful.
> You can implement as many finite state machines as you like. But this
> is not the XEP for that, this is just to turn them on/off. Let's keep
> it simple for once, folks :)
I have to agree with Matthew. What this XEP offers is, by itself, useful. Yes, it quite simplistic, leaving the choice of how to optimize to the server. This is useful by itself.
I personally rather not go down the rathole of 'exact finite state machines'... or 'profiles'. But, hey, if that's what you want, you can write a XEP just as well as anyone else.
More information about the Standards