Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
Only my two cents... You should not forget the other side and for e.g. the popular protocols ICQ and MSN. In a nutshell both protocols support the Invisible mode (in MSN it's named "appear off-line") and this is only annoying in both protocols. Take a look at the other side, you have a list full of off-line contacts, but many contacts write you messages. What's the sense of it? It's annoying! "... that's my choice", sorry, but I am not agree, stay off-line if you don't want to chat or keep the possibility that the user from the other side can see you and make sure "Invisible" is not a "normal" mode. Therefore, in my opinion, 3.1.2. makes sense. Peter -- Lastwebpage Lastwebpage's Profile: http://www.jabberforum.org/member.php?userid=41 View this thread: http://www.jabberforum.org/showthread.php?t=1903
Re: [Standards] XEP-0237: version == sequence number?
2009/4/24 Christoph Terwelp : > > Am 24.04.2009 um 14:10 schrieb Matthew Wild: > >> On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp wrote: >>> >>> If the ver attribute is some kind of a hash of the roster, a additional >>> feature could be added, to inform the client which method was used to >>> generate the hash. So the client can check the current roster. This way >>> corrupted rosters can be detected and no user interaction is required. >>> >> >> I'd rather keep it opaque to the client. Rosters shouldn't get >> corrupted during transfer, that's what TCP is for :) > > I don't suggest they could get corrupted during transfer, but because of a > client malfunction or a system crash. > I think you are complicating things way too much. If the client's cache gets corrupted, it probably isn't loadable anyway. I would let the ver be opaque for client. The implementation notes would then simply explain the ideas behind minimal implementation with hashes and more sophisticated implementation with integer numbers.
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
On Fri Apr 24 16:31:20 2009, Joe Hildebrand wrote: Sorry I'm so far behind. Any chance XEP-265 could have a framing parameter in the Jingle portion? Some folks might like to just use BEEP instead of the framing mechanism specified in the XEP. Or at least a BEEP-lite - we (Isode) may actually produce a spec for the MPP protocol that is, more or less, that - we use it for internal fast comms in our products already. But in any case, yes, a framing mechanism sounds great. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: OutOfBand Stream Data
Sorry I'm so far behind. Any chance XEP-265 could have a framing parameter in the Jingle portion? Some folks might like to just use BEEP instead of the framing mechanism specified in the XEP. On Thu, Mar 12, 2009 at 5:19 PM, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: OutOfBand Stream Data > > Abstract: This specification defines how to send parts of an XML stream over > a direct connection between peers. This allows to send large stanzas or > binary data without blocking the XML stream for other stanzas. > > URL: http://www.xmpp.org/extensions/inbox/outofband.html > > The XMPP Council will decide at its next meeting whether to accept this > proposal as an official XEP. > > -- Joe Hildebrand
Re: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI
-Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Will Thompson Sent: 04/23/2009 1:51 PM To: XMPP Standards Subject: [Standards] XEP-0816 (Invisible Command) mandates ridiculous UI Hi, I was just glancing over XEP-0186, and I noticed the following section: > 3.1.2 Client Handling This UI seems ridiculous to me: if my client did this, it would really annoy me. If I'm invisible but want to message a contact, that's my choice. My client shouldn't get in the way (unless I want it to, which I don't). Unfortunately, per the XEP a client that behaves how I want rather than as above is buggy. Perhaps this section could be removed, or rephrased as one possible UI? XEPs mandating particular UI behaviour seems like a bad idea in general, especially when the mandated behaviour is undesirable. :) -- I agree with you. XEP's should not be mandating client behavior, except for client protocol behavior. I would for sure never implement it this way either. I would vote for removing section 3.1.2. Thanks
Re: [Standards] XEP-0237: version == sequence number?
Am 24.04.2009 um 14:10 schrieb Matthew Wild: On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp wrote: If the ver attribute is some kind of a hash of the roster, a additional feature could be added, to inform the client which method was used to generate the hash. So the client can check the current roster. This way corrupted rosters can be detected and no user interaction is required. I'd rather keep it opaque to the client. Rosters shouldn't get corrupted during transfer, that's what TCP is for :) I don't suggest they could get corrupted during transfer, but because of a client malfunction or a system crash. The hashing algorithm of each server would be different anyway, and I don't see that clients would want to support each and every one individually. Maybe, but choosing a hashing algorithm in the XEP would improve the chances that client and server do use the same one. Christoph
Re: [Standards] XEP-0237: version == sequence number?
On Fri, Apr 24, 2009 at 1:02 PM, Christoph Terwelp wrote: > > Am 23.04.2009 um 20:13 schrieb Peter Saint-Andre: >> >> His argument was that the server might make the 'ver' attribute >> something like a hash of the roster, which would be opaque to the client >> but meaningful to the server so that it could figure out if it would >> return an empty IQ-result or the full roster (leaving aside the roster >> push for now). That seems like a perfectly acceptable approach to me as >> a minimal implementation, so I'm wondering if we want to say that the >> 'ver' value needs to be opaque to the user but meaningful to the server, >> and that one possible implementation is a strictly increasing sequence >> number. > > If the ver attribute is some kind of a hash of the roster, a additional > feature could be added, to inform the client which method was used to > generate the hash. So the client can check the current roster. This way > corrupted rosters can be detected and no user interaction is required. > I'd rather keep it opaque to the client. Rosters shouldn't get corrupted during transfer, that's what TCP is for :) If we /did/ want any such corruption detection then it belongs in another XEP in my opinion, rosters aren't the only thing you want to check. The hashing algorithm of each server would be different anyway, and I don't see that clients would want to support each and every one individually. Matthew.
Re: [Standards] XEP-0237: version == sequence number?
Am 23.04.2009 um 20:13 schrieb Peter Saint-Andre: His argument was that the server might make the 'ver' attribute something like a hash of the roster, which would be opaque to the client but meaningful to the server so that it could figure out if it would return an empty IQ-result or the full roster (leaving aside the roster push for now). That seems like a perfectly acceptable approach to me as a minimal implementation, so I'm wondering if we want to say that the 'ver' value needs to be opaque to the user but meaningful to the server, and that one possible implementation is a strictly increasing sequence number. If the ver attribute is some kind of a hash of the roster, a additional feature could be added, to inform the client which method was used to generate the hash. So the client can check the current roster. This way corrupted rosters can be detected and no user interaction is required. Christoph
Re: [Standards] XEP-0237: version == sequence number?
On Fri, Apr 24, 2009 at 10:22 AM, Dave Cridland wrote: > On Thu Apr 23 19:30:29 2009, Matthew Wild wrote: >> We would need to decide what to do where we currently set ver='0' though. > > We just need to stick with some ver value which is special. An empty string > works. > I'm happy with that.
Re: [Standards] XEP-0237: version == sequence number?
On Fri, Apr 24, 2009 at 11:10 AM, Dave Cridland wrote: > On Fri Apr 24 09:37:57 2009, Fabio Forno wrote: >> >> Sorry but I don't get the purpose of this. Isn't sufficient to omit >> ver for bootstrapping? > > Not quite, since you wouldn't get the ver attribute added onto the pushes. oh yes, stupid me. perhaps an empty ver is the best alternative to a new attribute -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] XEP-0237: version == sequence number?
On Thu Apr 23 19:30:29 2009, Matthew Wild wrote: On Thu, Apr 23, 2009 at 7:13 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just chatted with Jonas Lindberg via IM about the requirement in > XEP-0237 that the value of the 'ver' attribute is a strictly increasing > sequence number. Other than the similarity to IMAP CONDSTORE, is there > any strong reason why this is (or seems to be) a MUST? > I'm in favour of it being opaque. I don't see any reason the client needs to know the sequence number, and it would help server-side implementations a lot. At the end of the day it is simply a token to mark for the server the current revision stored by the client. Failing to recognise the revision the server can simply send the full roster anyway. The only reason I prefer a strictly increasing number is that it makes things much easier to debug, from a client authors perspective. But I'm not going to object if the consensus is to go for something much more opaque. We would need to decide what to do where we currently set ver='0' though. We just need to stick with some ver value which is special. An empty string works. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] XEP-0237: version == sequence number?
On Fri Apr 24 09:37:57 2009, Fabio Forno wrote: Sorry but I don't get the purpose of this. Isn't sufficient to omit ver for bootstrapping? Not quite, since you wouldn't get the ver attribute added onto the pushes. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] XEP-0237: version == sequence number?
On Thu, Apr 23, 2009 at 8:36 PM, Peter Saint-Andre wrote: > >> We would need to decide what to do where we currently set ver='0' though. > > Yeah, I was thinking about that too. I suppose it could still be zero or > some non-opaque string (bad), or that we could add another attribute > (bootstrap="true"?) rather than overload 'ver'. > Sorry but I don't get the purpose of this. Isn't sufficient to omit ver for bootstrapping? -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
