On Thu, Jul 19, 2012 at 3:40 PM, Kevin Smith <[email protected]> wrote:
> On Thu, Jul 19, 2012 at 8:18 PM, Mark Rejhon <[email protected]> wrote: > >> If I was to implement 301 and 308, but not RTT correction (the > >> intersection), another client would send me RTT corrections - a > >> significant number of stanzas that I'll then ignore. I won't fail in > >> any interesting way (although the UX will be quite odd), but we > >> generally try to design protocols that don't send unsolicited stanzas > >> that the recipient will be unable to process (or will misinterpret). > > > > That's not true... > > It's 100% backwards compatible! > > I didn't claim it wasn't backwards compatible! "I won't fail in any > interesting way" > > > Backwards compatible behavior (End User Viewpoint) > > The retroactive real-time edit will temporarily appear as if it was a > brand > > new message. Basically, the real-time message will be a *copy* of the > old > > message, while the retroactive edit is taking place. When the edit is > > finished, the real-time message disappears and the edit shows up above in > > the last message. > > Right, it's a bit of a goofy user experience. > > > Thus, adding new disco is > > overkill (shooting a fly with a shotgun) when the developer already has > the > > full flexibility of choosing these two perfectly reasonable choices, > > correct? As a result, I'm somewhat stumped why you think disco is > necessary > > for this situation. > > I'm similarly baffled why you think of disco as a shotgun - this is > the usual XMPP way of doing things - it's so cheap as to almost be > free for a developer - who will need to already have written the code > for handling disco/caps to be able to implement the spec already, and > so this becomes a one-line-of-code check. > Only if it's a good, comprehensive, well-documented XMPP library. I've also been working with some really crappy XMPP implementations. Please consider the charity angle too -- Some deaf organizations can't hire good developers; and may have to stick with crappy XMPP implementations, that doesn't make it a one-line-of-code check for disco stuff. I've seen some quite nasty code out there, too. (Background info: RTT being a technology of interest to the deaf, and also Canada had a $300 million dollar cut to Canadian Hearing Society, and grant money is hard to come by for deaf development in Canada.) > > Can you re-explain why you still think disco is needed for the 301+308 > case > > without retroactive 301? > > It'll prevent stanzas being sent to a client that it doesn't understand. > But from my viewpoint, that's not a problem: -- We already have disco for XEP-0301 and we already have disco for XEP-0308 ! -- We have no invalid stanzas at all -- if I add it to XEP-0301, then the namespace is valid. Then there is no stanzas that the client doesn't understand, since 'id' would already be documented in the upcoming v0.4 of XEP-0301 and the business rules of it being allowed to be ignored, is "complying with XEP-0301 allowing id to be ignored" rather than "an attribute that I don't understand" This edge case doesn't need _additional_ disco for such an edge case of 0301+0308 without 0301 retroactive, when the developer has two perfectly good choices. The one-line code (for the good XMPP libraries) is not worth the pollution of 1/3 page of inflation to the document for additional confusing disco that 99%+ of implementers will never use. (especially as I have low-skilled programmers asking me for help about XEP-0301 already -- I sometimes refer them to the chapter "Basic Real Time Text" at http://xmpp.org/extensions/xep-0301.html#basic_realtime_text ...) Right now, I still have mixed feelings about having to comply with XEP-0030 and XEP-0115 (I've now already improved the upcoming v0.4 to include both, to be similiar in spirit to other XEP's) -- given some situations requiring a fallback method (refer to earlier discussion). Right now, I really do not want to complicate 0301 even further with having two separate disco parameters (including an additonal separate disco parameter for 0301 retroactive) -- it's already a big spec, and I feel the edge case is not worth confusing 99% of XEP-0301 readers. There's been interest by other people for other parameters that are more important, such as negotiation of a mutually-agreed transmission interval. (including server-negotiated transmission interval, such as automatic rate-limiting real-time text in MUC, etc). All presently beyond the scope of XEP-0301 today, and possibly belongs in a future "enhancements" XEP. Presently, there are higher priorities at the disco/feature negotiation level at the moment, and I've excluded them too. After all, if a developer goes to the effort of implementing 0301 + 0308, it's quite easy to support 0301 retroactive, anyway. It might be more effort for some of you than a one-line change, but it's worth avoiding confusing 99% of spec readers that won't ever need retroactive 0301 (saving spec inflation to an already-big spec) > If we can agree to call a simultaneous LAST CALL before the end of this > > month (I was hoping for earlier, but there's been so much discussion), > so we > > can bring both 0301 and 0308 to Draft status roughly simultaneously -- I > > will go ahead and immediately add the 'id' parameter to XEP-0301. > > I'm happy to ask for LC on 308. > Ok, agreed. I am now extending XEP-0301 to support real-time retroactive editing, since it'll inflate the spec by only approximately two paragraphs or so. My goal is to send a v0.4 update to XEP-0301, and ask you to review it to tell me if you think it's ready for LAST CALL. If it is, then let's commence, shall we? :-) Thanks Mark Rejhon
