[Standards] XEP-0136: comments about auto save and preferences

Guus der Kinderen guus.der.kinderen at gmail.com
Wed Jun 23 17:39:39 UTC 2010


2010/6/13, Steven te Brinke <s.tebrinke at student.utwente.nl>:
> Hello,
>
> When reading XEP-0136 I discovered some confusing properties. I will
> describe
> these and propose changes that make them more intuitive to me. I am not sure
> whether the things I propose are better than the official XEP, so let me
> know
> what you think about it.
>
> The auto save preference is quite confusing to me. If I am right, all
> preferences are global, except the auto save preference, which can be set
> per
> stream by using scope='stream'. The idea that it can be set per stream
> sounds
> quite good, but the way it is done is quite strange to me:
> 1) The usage of scope is explained in the XEP, but the scope element is not
> part of the given schema.
> 2) The auto element can be set as well inside as outside the pref element
> without having different semantics.
> 3) Setting an auto with scope='stream' implies removing the auto with
> scope='global'.
>
> Maybe number 3 is done for a specific reason, but I do not know in which use
> case it is useful. Consider the following situation:
> My server has archiving disabled by default and I want to archive all
> messages, so I set <auto save='true' scope='global'/>. At home I use a
> client
> with built in archiving, so I set <auto save='false' scope='stream'/> to
> disable archiving for this session only. However, when I now login with any
> other client, archiving is disabled because the server default is used.
> (Setting auto with scope='stream' was overwriting the one with
> scope='global'.)
>
> Thus, IMO it is undesired that the setting for a stream overwrites the
> global
> setting. Therefore I propose the following change: remove the scope
> attribute
> from the auto element and define two separate elements: one inside the prefs
> and one outside. The former should be global and the latter per stream. If
> both are present, the server should use the latter. This way, no
> functionality
> is lost and now both properties can be configured independently.
> Furthermore,
> it makes all preferences in the prefs element global, which is more
> intuitive.
>
> Regarding the streams, there is one more thing that is unclear to me. The
> spec
> states: "Server implementations SHOULD remove all <session/> elements when
> stream is closed."
> However, a user can have multiple streams (e.g. by being online on multiple
> PCs) and there is no definition to which stream a session element belongs.
> My
> propose is to remove this sentence altogether, because I think it is not
> really desired to have sessions removed at the end of a stream. The
> expiration
> will remove the session when appropriate. Consider the following situation:
> During a secret conversation with Bob we both turn off archiving for this
> session only. For a reason unknown to me, Bob goes suddenly offline. Because
> I
> was busy typing, I only notice this after I have send another message. This
> message will be archived at Bobs side because his stream was closed before I
> send the message. This is not what we desired. Only if the session element
> had
> expired normally, the desired effect would have been achieved.
>
> Another point are changes to preferences. These are pushed to every resource
> which has retrieved the preferences before. I assume this is done to allow
> the
> client to have an up to date view of the preferences. However, item removes
> are not pushed to the clients, so clients cannot maintain an up to date view
> from the pushed changes. Therefore, IMO this behaviour should be changed.
> Because I do not know how clients will use this information, I cannot say in
> which way it should be changed. There are many possibilities:
> 1) Also push removes. This adds additional complexity to the protocol, but
> allows clients to stay updated with minimal overhead.
> 2) Always push the full settings on a change, not only the changes. Provides
> the same functionality as 1 using less complexity, but more overhead.
> 3) Push no information about changes. Minimal overhead, but removes the
> ability to stay up to date.
> 4) Use 3, but additionally store the settings in a pubsub node, so all
> interested clients can stay up to date. Has many good properties: no
> overhead
> when clients are not interested, less complexity in this protocol. Downside
> is
> that in order to use it, pubsub support is required (but that will be
> required
> for many features anyway).
>
> Note that when sessions are expired, they can be removed from the
> configuration
> by the server. IMO this should also be considered a change of configuration,
> but at least the expected behaviour in this situation should be documented
> too.
>
> Cheers,
> Steven
>

-- 
Verzonden vanaf mijn mobiele apparaat



More information about the Standards mailing list