2009/4/17 Peter Saint-Andre <[email protected]>: > Ahoj Jirka, > > On 4/16/09 8:39 PM, Jiří Zárevúcký wrote: >> 2009/4/17 Peter Saint-Andre <[email protected]>: >>> 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. >
Actually, I described an error scenario that could occur (but probably never would, and even if it did, nobody would likely notice) when both client and server utilize a specific optimization. :) which is probably making half of this thread a truly regrettable waste of your time... sorry about that... :)
