Ahoj Jirka, On 4/16/09 8:39 PM, Jiří Zárevúcký wrote: > 2009/4/17 Peter Saint-Andre <stpe...@stpeter.im>: >> I think you're making it too complicated for the typical usage. >> >> Peter >> > > Yeah. You are probably right. These are just nuances that would affect > very little people throughout the whole existence of the protocol, but > given they don't make anything more complex or introduce any > inconveniences for anyone, I think they are worth doing. For all we > know, someone's aggravation over few second longer delay when loading > roster can ultimately lead to World War III... :-D
I think that the things you are describing fall into the category of
optimizations that a smart client can implement to improve the user
experience. But we don't need to describe all that in the spec ("in the
unlikely event that you get disconnected after receiving some but not
all of the roster pushes, cache what you've received so far but then
when you reconnect you can shave a few seconds off the reconnection
process by requesting the roster based on the version of the last roster
push you cached, not the last full roster update"). That kind of thing
is great but IMHO it doesn't really belong in an RFC.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
