2009/5/13 Jiří Zárevúcký <zarevucky.j...@gmail.com>:
> 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*
>
Programmers for whom ver='qAxdnWNcA+lYf7CoN5wpBsvVVno=' would be
entirely impossible... I think those exact programmers are the reason
for not using ver='1' :-)
The XEP is short and clear. The 'ver' attribute is an opaque string
for clients, and client programmers shouldn't care what it's value is.
I don't see a problem here.
--
Waqas Hussain
