2009/5/12 Peter Saint-Andre <stpe...@stpeter.im>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 5/9/09 12:52 PM, Jiří Zárevúcký wrote:
>> I have read the text again after a while and the following text got my
>> attention:
>>
>>> If a series of roster modifications result in a roster item that does not
>>> differ from the
>>> version cached by the client (e.g., a modification to the item's 'name'
>>> attribute and
>>> then a modification back to the original value), the server SHOULD NOT
>>> consider the
>>> item to have been modified for purposes of roster versioning and therefore
>>> SHOULD NOT
>>> push the item to the client in an interim roster push.
>>
>> That part is not very useful, since servers will hardly keep track of
>> every previous roster version. I don't even want to think about the
>> CPU overhead that will kill the cluster every 30 minutes (that's a
>> hyperbole of course). > The simplest "full featured" implementation
>> consists of integer version numbers and "mver" field for every roster
>> item.
>
> This is purely an implementation decision and I think we need to remove
> the conformance language here (i.e., no MUST, SHOULD, SHOULD NOT, MAY).
> If the server chooses the "hash complete roster" approach then it won't
> send the push. If the server chooses the "integer version numbers"
> approach then it will send the push. End of story.
>
>> Server will then send all the items whose mver is greater than
>> client's ver. Any throughout checking would hardly ever have any
>> benefit.
>
> What is mver?
>
The same relation as with time and mtime on files. It's the version of
last change.
>> -----
>>
>> About the opaque vs. integer examples dilemma. I think if someone
>> really doesn't read the text, his implementation won't work at all
>> anyway. The examples are kinda confusing this way. If you really want
>> some opaque strings there, use "AAAAA", "BBBBB", "CCCCC" or something
>> like that, so the sequentiality is obvious.
>
> A sequence number is not really opaque, is it? The examples currently
> use the "hash complete roster" approach. I would prefer to err on the
> side of not misleading clients about sequentiality ("the examples have
> AAAAA and BBBBB so I suppose the next 'ver' will be CCCCC" and then the
> client breaks when that's not the case).
>
> Peter
>
Ok, so in order to not confuse stupid programmers with a specific
implementation, we will confuse them with one entirely impossible. I
get your thinking *THUMBS UP*
