Thanks for the answers! A few more thoughts.
I'd be happier if a standard didn't *assume* a low number of user initiated actions, even if that is the reasonable and most probable use case here. Client should be dumb and say 'hey, please add this jid to "always"' and server should be smart enough to add it. Client shouldn't need to maintain state of jids just to modify one entry. Consider the following. If a window has a checkbox "Archive this conversation", it should trigger a small <iq/> changing the setting for conversation with that particular user. It shouldn't trigger download of a list containing potentially hundreds of jids, modify this list, upload it, then receive it for the second time (containing just one modification). And if someone modified the settings in the meantime, what next? It isn't a *completely* unreasonable scenario -- download of several kilobytes of data over a laggy EDGE connection and upload of several kilobytes of data over a laggy EDGE connection gives enough time for another connection to interfere. Yes, it's improbable, but not impossible. Should XSF standardize possible transmission of kilobytes of data for a single checkbox toggle? Is there a downside to having add and remove operations? On Mon, Jun 23, 2014 at 8:00 PM, Kim Alvefur <z...@zash.se> wrote: > > 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. > Here, I was asking about reading the state, and not about modifying the state :-) As far as I can see, the XEP specifies only that the full state will be returned upon modification; it does not state how to actually retrieve the state without first transmitting the state. -- Ivan Vučica i...@vucica.net
