I know this thread is going to sleep, but I'd like to stick my oar in. :-) On Tue, Aug 6, 2013 at 9:15 PM, Daniele Ricci <[email protected]>wrote:
> Please correct me if I'm wrong at any point, just to be sure I > understand XEP 198 and how I can use it in the right way. > > XEP-0198 is designed to make a stream: - Reliable: You know what has definitely been received by the peer. - Recoverable: You can have a stream span TCP connections, in effect, without duplication or loss. But note this *only* has an effect for streams; "chat sessions" span multiple streams - unless you're talking to a server, or using XEP-0174 (Serverless messaging, in case I've got the number wrong) - and so all this is doing is making each leg of the journey reliable. That's important, but not sufficient. > In my case, I can only use the 'h' attribute to store the server-side > message ID. Which I can't do according to the spec. > > Right - h is purely a count. Because it's only one stream, rather than end-to-end, we can do this, and it's sufficient. We could have had <a/> and <r/> contain random guids or something, but then people would have expected to be able to insert semantic meaning into them, and they don't need that. <a/> is the conversational equivalent of saying "Right?" at the end of a sentence, and <r/> is the equivalent of saying "Uh-huh" and nodding politely. You don't need to figure out which sentences have been received, because it's just "everything up until this point". But just like a conversation where one side is just grunting and nodding, while you know they've heard, you don't know if there was anything more. > But the biggest and main issue is: a receipt is actually part of a > message. It's not stream management; it means Alice will receive a > delivery receipt when message has been delivered (and acknowledged) by > Bob. I can't just throw off <r/> at any time for this purpose - it > would not be stream management any more. That's why I think I need > something half XEP 198 and half XEP 194. > > And you're right - except you don't want half '198 and half '184, you actually want all of both. Whilst XEP-0198 makes streams reliable, to make chat sessions reliable to need XEP-0184, which will then mean you can reliably send a message - and reliably get a receipt back when it's delivered. The reason you need both, despite them looking superficially similar, is that without any XEP-0198 in place you can't actually tell if it was the message that was lost or the XEP-0184 receipt, and so while the safe thing to do is warn the user and possibly resend, that may be very irritating for the recipient. The reason you need both, despite them looking superficially similar, is that without any XEP-0198 in place you can't actually tell if it was the message that was lost or the XEP-0184 receipt, and so while the safe thing to do is warn the user and possibly resend, that may be very irritating for the recipient. The reason you need both, despite them looking superficially similar, is that without any XEP-0198 in place you can't actually tell if it was the message that was lost or the XEP-0184 receipt, and so while the safe thing to do is warn the user and possibly resend, that may be very irritating for the recipient. I hope that makes things clearer, Dave.
