Re: [Standards] XEP-0136: comments about auto save and preferences
2010/6/13, Steven te Brinke s.tebri...@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
Re: [Standards] XEP-0136: comments about auto save and preferences
On 13 June 2010 15:22, Steven te Brinke s.tebri...@student.utwente.nl wrote: Hello, Hello! Ignoring Guus's mobile's fascination with your message... 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. Most of what you have said makes sense. A new version of XEP-0136 was recently published, and the council have added a note about the perceived complexity of the current spec, and that it could likely be drastically simplified. The XEP is currently being implemented server-side in Prosody for Google Summer of Code - I expect some feedback to result from that, and given the resulting client and server experience we should be able to start banging this protocol into good shape at last. Matthew
Re: [Standards] XEP-0136: comments about auto save and preferences
I'm sorry guys. It appears that every time I start the gmail app on my phone, a new, empty response is sent. On 24 June 2010 01:19, Matthew Wild mwi...@gmail.com wrote: On 13 June 2010 15:22, Steven te Brinke s.tebri...@student.utwente.nl wrote: Hello, Hello! Ignoring Guus's mobile's fascination with your message... 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. Most of what you have said makes sense. A new version of XEP-0136 was recently published, and the council have added a note about the perceived complexity of the current spec, and that it could likely be drastically simplified. The XEP is currently being implemented server-side in Prosody for Google Summer of Code - I expect some feedback to result from that, and given the resulting client and server experience we should be able to start banging this protocol into good shape at last. Matthew
Re: [Standards] XEP-0136: comments about auto save and preferences
-- Verzonden vanaf mijn mobiele apparaat Not quite sure why my mobile decided that it was a good move to reply to the original e-mail message with a blank message. Certainly was not intentional. Sorry for this. - Guus
[Standards] XEP-0136: comments about auto save and preferences
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
Re: [Standards] XEP-0136: comments about auto save and preferences
2010/6/13, Steven te Brinke s.tebri...@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
