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.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
