On Sat Sep 11 00:15:39 2010, Tobias Markmann wrote:
Some feedback following inlined.
Responses (where there was disagreement).
On 03.09.10 12:19, Dave Cridland wrote:
>> @@ -217,11 +219,16 @@ S: <failed xmlns='urn:xmpp:sm:2'>
>> <li>The 'h' attribute identifies the last
>> <strong>handled</strong> stanza (i.e., the last stanza that the
>> receiver will acknowledge as having received).</li>
>> </ul>
>> <p>An <a/> element MUST possess an 'h' attribute.</p>
>> - <p>An <r/> element SHOULD NOT possess any
attributes.</p>
>> + <p>An <r/> element has no defined attributes.</p>
>
> Being picky.
I don't care. Guess it makes only a difference for those who intent
to
break the spec.
No, it means that future extensions could add to the element without
contradicting this.
> Tobias's code repeats <r/>'s at times, and I found it did no
harm. Nor
> did responding to them. Therefore I'm allowing the behaviour,
since I
> think it'll be quite common.
>
This is by accident.
The way I implemented it in Psi is having a sending queue of unacked
stanzas. If that has more than 5 or so elements in it I'll send an
ack-request each 3 or so messages. This is so I don't send an
ack-request for each message after more than 5 unacked messages are
in
the queue.
In the case the user just enters one message Psi waits 30 seconds
until
it requests an ack even though the send queue has less than 6
stanzas in it.
Why it repeats <r/>'s at times for a single stanza is up to be
discovered in an investigation.
You might not want to be doing it, but as I say, I couldn't see any
interoperablility problem due to your doing it, so I'm quite content
to allow it, and certainly mandating that receivers should handle the
case seems reasonable (especially as they all do at this stage).
What also came to mind while implementing XEP-0198 is that it might
be
nice to have one value in the unsignedInt data type value range for
an
uninitialized/ack hasn't started yet value. One could start
counting at
1 instead of 0 to archive this.
In the end it also works without that, true. Wonder if it's worth a
change.
How would you use that?
At the end of section 6 it says "If the number of unacknowledged
stanzas
is greater than or equal to the value of the 'stanzas' attribute, a
throttled peer MUST NOT send any further stanzas.".
It would be nice to mention possible UI consequences of this.
I've never really bought into the whole throttling thing, but yes, I
agree some kind of discussion on this would be nice.
Section 8 (Stream Closure) reads like it also applies to basic
acking
scenario without resumption support. However for a server it doesn't
make any sense to keep the session after the client's TCP
connection got
closed since there's no way to continue the acking session with the
corresponding h-values. In this case an unavailable presence should
be
send out like a abnormal disconnection of C2S TCP stream without
usage
of XEP-0198.
Good point.
Of course it makes sense to maintain the session if resumption is
supported and the C2S TCP stream breaks for a limited amount of
time. I
think the XEP should recommend a time span here, while I don't know
what
could be useful here. Maybe 30 minutes or so?
I have no idea. It's also not entirely clear to me that a server
should cheerfully pretend the client is entirely online during the
connectivity break.
Finally, I think there might be an advantage in being able to respond
to a <resume/> with something saying "I got stanzas up to X, but I
gave up waiting for you so you'll have to start over."
The cost of maintaining a single integer is way lower than the cost
of maintaining a bunch of buffered stanzas.
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
