[Standards] Proposed XMPP Extension: Client State Indication

Matthew Wild mwild1 at gmail.com
Tue Aug 19 19:53:58 UTC 2014

On 19 August 2014 19:30, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
> Tue, 19 Aug 2014 10:21:42 -0700
> Kurt Zeilenga <kurt.zeilenga at isode.com> wrote:
>> 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:
>> >
>> > 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. What we really need is to throttle
> presences when the client is in 'inactive' state. I don't think there
> are multiple ways in doing this.
> I, as an XMPP server developer, want to take well described FSM and
> implement it.
> Again, as an XMPP server developer I don't know what to do with client
> inactivity. It's pointless for me.

There are definitely multiple ways of doing it. I've already
implemented two or three different approaches over several years, and
I can always think of more things that I would like to try. If you
just want an out-of-the-box protocol to implement and not have to
think about, you're right, CSI is certainly not what you are looking
for. Maybe down the line someone will provide that on top of CSI, but
it's not something I'm pursuing right now.


More information about the Standards mailing list