On 7/19/12 2:09 PM, Mark Rejhon wrote: > On Thu, Jul 19, 2012 at 3:40 PM, Kevin Smith <ke...@kismith.co.uk > <mailto:ke...@kismith.co.uk>> wrote: > > On Thu, Jul 19, 2012 at 8:18 PM, Mark Rejhon <marky...@gmail.com > <mailto:marky...@gmail.com>> 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.
We don't design around crappy implementations. Service Discovery is just about as core as you can get in XMPP without being in the RFCs, it's been around since 2003, all self-respecting libraries support it, etc. > 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. Why do organizations for the hearing-impaired need to write their own libraries in order to write their own clients? Just use one of the existing open-source libraries. That's what libraries are for, after all. > 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? :-) Sounds good! Peter -- Peter Saint-Andre https://stpeter.im/
