On Aug 19, 2014, at 11:30 AM, Evgeny Khramtsov <[email protected]> wrote:
> Tue, 19 Aug 2014 10:21:42 -0700 > Kurt Zeilenga <[email protected]> wrote: > >> >> On Aug 19, 2014, at 10:05 AM, Matthew Wild <[email protected]> wrote: >> >>> On 19 August 2014 17:21, Evgeny Khramtsov <[email protected]> >>> wrote: >>>> Tue, 19 Aug 2014 11:30:18 +0100 >>>> Matthew Wild <[email protected]> wrote: >>> >>> 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. > > Seems like you don't get me. Well, when you said you need an exact state machine, I guess I should have just pointed out that this spec does describe an exact two state FSM... :-) What you seem to what, and I must admit I'm guessing to some degree, is guidance on how to implement behaviors of one those states, namely the inactive state, or possibly you want the spec to be quite prescriptive in the behaviors associated with each of the states. If what you believe the community would benefit from implementation guidance, I suggest you write up some text. I would recommend placing this text in a separate informational XEP instead of incorporating it into a non-normative section of this spec so as not to hinder this specs progression on the standards track due to likely ever changing guidance (as XMPP is continually evolving). If you rather have a different protocol, such as one which was more prescriptive in the behaviors of the server's behaviors when the client is inactive, then you should write up a separate XEP because, as I think Matthew has indicated, this spec is intended to define a simple protocol which is more descriptive or even just suggestive of the behaviors. > What we really need is to throttle > presences when the client is in 'inactive' state. 6121 presence is only one of many protocols needing to be optimized for network-constrained clients, such as mobiles. There's also XEP 45 presence, PEP, chat-state notifications, real-time text, ... > I don't think there > are multiple ways in doing this. I can think of two completely different classes of implementation approaches for optimizing traffic, both of which are applicable to XMPP presence (including both 6121 and XEP45). -- Kurt
