On 4/16/09 9:23 PM, Jiří Zárevúcký wrote: > 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... :)
Jiří, it's better to raise issues than to ignore them. Sometimes we conclude that the issue isn't very serious, but often we don't know that until we discuss it for a while. So keep posting! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
