Hi Dave, thanks for your delightful answer. Actually I was going to reply with pretty much the same arguments, I was looking for the time to write that... you saved me from a long writing :-)
Anyway Dave has perfectly catched my needs. Although I ended up defining my own extension, I really would like to standardize it or (if possible) use an existing XEP. p.s. the last paragraph came 3 times. On Thu, Aug 8, 2013 at 11:37 AM, Dave Cridland <[email protected]> wrote: > 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. -- Daniele
