Re: [Standards] Move CSI to Last Call ("Proposed")

On 29 July 2015 at 15:01, Sam Whited wrote: > On Tue, Jul 28, 2015 at 4:00 AM, Florian Schmaus wrote: >> The client knows for example that the roster presence information is >> up-to date. Basically I've an use case of a client using CSI which needs >> to take a decision based on the current pres

Re: [Standards] Move CSI to Last Call ("Proposed")

On Tue, Jul 28, 2015 at 4:00 AM, Florian Schmaus wrote: > The client knows for example that the roster presence information is > up-to date. Basically I've an use case of a client using CSI which needs > to take a decision based on the current presence state of the roster > items. Imagine the foll

Re: [Standards] Move CSI to Last Call ("Proposed")

* Sam Whited [2015-07-28 17:04]: > On Tue, Jul 28, 2015 at 1:57 AM, Matthew Wild wrote: > > Out of curiosity, what clients do you know of that are using it? > Conversations, Kontalk, Converse.js, Bluejabb, probably others. yaxim has a quick&dirty google:queue implementation that at least prosod

Re: [Standards] Move CSI to Last Call ("Proposed")

On Tue, Jul 28, 2015 at 1:57 AM, Matthew Wild wrote: > Out of curiosity, what clients do you know of that are using it? Conversations, Kontalk, Converse.js, Bluejabb, probably others. >From personal experience, it does a great job in Conversations (with ejabberd on the server end). I have hard

Re: [Standards] Move CSI to Last Call ("Proposed")

* Christian Schudt [2015-07-28 10:22]: > I think this has already been discussed once, but wouldn't it be more > intuitive to use IQ semantics for this instead of sending a message > which confirms the (de)activation? +1 for an IQ. Basically just what google:queue does, with a properly declared n

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28.07.2015 11:58, Dave Cridland wrote: > On 28 July 2015 at 10:13, Florian Schmaus > wrote: > On 28.07.2015 11:05, Dave Cridland wrote: > > On 28 July 2015 at 10:00, Florian Schmaus > >

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28 July 2015 at 10:13, Florian Schmaus wrote: > On 28.07.2015 11:05, Dave Cridland wrote: > > > > > > On 28 July 2015 at 10:00, Florian Schmaus > > wrote: > > > > On 28.07.2015 10:20, Dave Cridland wrote: > > > > > > > > > On 28 July 2015 at 08:22, Fl

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28.07.2015 11:11, Edwin Mons wrote: > On 28/07/15 11:05, Dave Cridland wrote: >> >> > Also, why wrap the server notification in a message, >> >> And not using a Nonza? Because most libraries provide a mechanism for >> callbacks matching a given filter only for Stanzas. It's my impres

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28 July 2015 at 10:11, Edwin Mons wrote: > On 28/07/15 11:05, Dave Cridland wrote: > > > Also, why wrap the server notification in a message, >> >> And not using a Nonza? Because most libraries provide a mechanism for >> callbacks matching a given filter only for Stanzas. It's my impression

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28.07.2015 11:05, Dave Cridland wrote: > > > On 28 July 2015 at 10:00, Florian Schmaus > wrote: > > On 28.07.2015 10:20, Dave Cridland wrote: > > > > > > On 28 July 2015 at 08:22, Florian Schmaus > >

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28/07/15 11:05, Dave Cridland wrote: > > > Also, why wrap the server notification in a message, > > And not using a Nonza? Because most libraries provide a mechanism for > callbacks matching a given filter only for Stanzas. It's my impression > as as XMPP client library developer

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28 July 2015 at 10:00, Florian Schmaus wrote: > On 28.07.2015 10:20, Dave Cridland wrote: > > > > > > On 28 July 2015 at 08:22, Florian Schmaus > > wrote: > > > > On 27.07.2015 23:29, Sam Whited wrote: > > > Hi all, > > > > > > I'd like to propose tha

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28.07.2015 10:22, Christian Schudt wrote: > I think this has already been discussed once, but wouldn't it be more > intuitive to use IQ semantics for this instead of sending a message which > confirms the (de)activation? I think Matt's intention is that stream behavior should not be controlle

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28.07.2015 10:20, Dave Cridland wrote: > > > On 28 July 2015 at 08:22, Florian Schmaus > wrote: > > On 27.07.2015 23:29, Sam Whited wrote: > > Hi all, > > > > I'd like to propose that the Council vote to move XEP-0452: Client > > State Indication

Re: [Standards] Move CSI to Last Call ("Proposed")

I think this has already been discussed once, but wouldn't it be more intuitive to use IQ semantics for this instead of sending a message which confirms the (de)activation? CSI feels similar to XEP-0186: Invisible Command and it uses IQ as well. I'd just appreciate consistency among XEPs and CS

Re: [Standards] Move CSI to Last Call ("Proposed")

On 28 July 2015 at 08:22, Florian Schmaus wrote: > On 27.07.2015 23:29, Sam Whited wrote: > > Hi all, > > > > I'd like to propose that the Council vote to move XEP-0452: Client > > State Indication into last call (the "Proposed State"), and then > > hopefully into draft afterwards. > > > > The XE

Re: [Standards] Move CSI to Last Call ("Proposed")

I for one using it in my project Kontalk. It saved me so much energy and bandwidth, in its simplicity it's very useful. Daniele On 28 Jul 2015 08:59, "Matthew Wild" wrote: > > On 27 Jul 2015 22:31, "Sam Whited" wrote: > > > > Hi all, > > > > I'd like to propose that the Council vote to move XEP

Re: [Standards] Move CSI to Last Call ("Proposed")

On 27.07.2015 23:29, Sam Whited wrote: > Hi all, > > I'd like to propose that the Council vote to move XEP-0452: Client > State Indication into last call (the "Proposed State"), and then > hopefully into draft afterwards. > > The XEP has been sitting dormant since it was last updated almost a > y

Re: [Standards] Move CSI to Last Call ("Proposed")

On 27 Jul 2015 22:31, "Sam Whited" wrote: > > Hi all, > > I'd like to propose that the Council vote to move XEP-0452: Client > State Indication into last call (the "Proposed State"), and then > hopefully into draft afterwards. > > The XEP has been sitting dormant since it was last updated almost a

[Standards] Move CSI to Last Call ("Proposed")

Hi all, I'd like to propose that the Council vote to move XEP-0452: Client State Indication into last call (the "Proposed State"), and then hopefully into draft afterwards. The XEP has been sitting dormant since it was last updated almost a year ago (2014-08-28), but this is not due to its being