2009/4/17 Dave Cridland <[email protected]>: > On Fri Apr 17 16:05:06 2009, Jiří Zárevúcký wrote: >> >> 2009/4/17 Dave Cridland <[email protected]>: >> > On Fri Apr 17 15:06:36 2009, Jiří Zárevúcký wrote: >> >> >> >> 2009/4/17 Peter Saint-Andre <[email protected]>: >> >> > >> >> > 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! >> >> > >> >> >> >> Sure, I will. >> >> I guess the only "issue" now is the unneeded restriction you added to >> >> the SVN based on my incorrect feedback. I mean the part "The client >> >> MUST NOT process any of the interim roster pushes until...". I think >> >> you can safely remove it again, as the reason for the change was >> >> proven invalid. >> > >> > While you're looking at this, what's your opinion on the empty roster >> > case? >> > (That is, when a roster becomes empty). >> > >> > It's an odd edge case, but I'm not sure the protocol handles this >> > usefully. >> > >> >> That's really tricky. And surely can't stay that way, since client >> wouldn't know, how to interpret it in some cases. >> >> I think it could be solved by sending interim pushes _first_, then an >> empty IQ result to mark interim pushes were all sent. >> What do you think? > > Or we could respond with "What you have is okay, I may send you some > pushes", by returning an empty result - we've established there's no need to > treat these pushes any differently to normal ones, after all. > > This then means that an empty roster is different to an empty result, and > means fewer octets for the optimal case. >
I completely agree. I think that knowing, how many versions are to be expected on startup, doesn't matter for any implementation.
