On 2014-06-23 20:25, Ivan Vučica wrote: > I've taken a few moments and looked more closely at XEP-0313. A few > comments follow, primarily about section "5.1 Simple configuration". > > This section can be interpreted as if settings for all jids have to be > retransmitted, even if only one change has been made. Doesn't that > introduce a possible race condition in case two clients attempt to make > an update at the same time? Doesn't that unnecessarily make the > transmitted stanza (or a received confirmation of the new preferences) > bloated?
This has been discussed at some point already. IIRC, the consensus was against doing anything about that. You would need to get preferences before changing them. I don't think they would normally be changed at the same time from multiple clients, as that should probably be a user-initiated action. > > Is there a reason for the syntax <always><jid>#textnode</jid></always>? > Why not, for example, <always jid="#jidhere"/>? Can <always/> and > <never/> repeat in the first place? If so, can there be more than one > <jid/> in each instance of <always/> and <never/>? You include one <jid/> element per jid under the <always> or <never> element. > > A server implementation can get around a lot of issues around > configuration by exposing ad-hoc commands. But, that doesn't let a > client design a nice UI. And, how does an archive configured using > ad-hoc commands map to simple configuration? A basic form might be something to standadise, probably with 'always' and 'never' as jid-multi fields and a 'default' field with the options 'always', 'never' and 'roster'. > > How does one read the simple preferences without modifying them? With > <iq type="get"/>? If so, can that be explicitly stated in the text of > the XEP? <iq type="get"> should never modify state. -- Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
