Hello Florian, You did an excellent job of pointing out a couple of mistakes I made. (Thank you!)
On Wed, Mar 7, 2012 at 7:43 PM, Florian Zeitz <[email protected]> wrote: > Thank you. Believe it or notm I have in fact used an instant messenger > before. I however fail to see how this is relevant to any of this. > The point is that such a "seamless" reconnect (from the receivers UI > point of view) is (for the sender) indistinguishable from, let's say, my > device crashing and me signing in with the same resource from a > completely different device almost immediately after. > That's true. The XEP-0301 spec allow real-time text to automatically appear again irregardless of how you reconnect (restart app, different client, manual relogin, automatic reconnect, etc). Even as the sender continuously types. Another reason I forgot to mention -- XEP-0301 works with concurrent login. With concurrent-login, logging in from separate applications, even from separate computers (phone vs PC). Real-time text still works, and it gets reinitialized via the regular reset retransmissions -- another useful purpose for retransmission. You can't always detect concurrent-logins especially since your online status stays online. All concurrent multiple-login clients successfully receive incoming RTT. Related scenario (crash & phantom concurrent login) -- Imagine that your client crashes (hopefully not due to XEP-0301 ;-) or it's abruptly terminated (i.e. by Task Manager) -- The crash occurs while the other person is sending incoming RTT. -- The other person sending you RTT doesn't notice you're offline yet because the XMPP server doesn't time you out instantly (turns you offline.). Sometimes timeout is longer than your ability to re-launch your chat program. -- You restart your client quickly -- The other person's still-in-progress RTT reappears in your software quickly, thanks to the event='reset' retransmissions. -- There is no offline/online status change in this situation, because the server still thinks there's 2 concurrent logins (including the original login that hasn't timed out yet after the crash) -- Since XEP-0301 is designed to work successfully with concurrent login, RTT works as expected, and causes no furter-contributing inconveniences. Related info about concurrent logins in Supplement document (including two different methods of handling incoming RTT from two or more concurrently logged-in clients) -- http://www.marky.com/realjabber/XMPP-RTT-Supplement_2011-06-17.pdf This is just background information about MUC and concurrent-logins (which XEP-0301 was designed to be compatible with), but has been left out of XEP-0301 spec, for simplicity. > I actually already specify this -- I already mention this as part of the > > "Error Recovery" -- that a client SHOULD do an event="new" or > event="reset" > > if the user comes back online. It is not currently a MUST because if > the > > client doesn't do it, it is not fatal to interoperability of real-time > text > > -- it just means real-time text automatically resumes a little bit later. > > (Using fewer "MUST"s is beneficial to a specification) > > > I can only assume you're talking about your working copy, because there > is not a single SHOULD requirement in that section in the published > version of XEP-0301. > Ooops, I meant "MAY". Thanks for correcting me! I'm referring to the word used in section 4.6.4 "Helping the Recipient Stay In Sync" http://xmpp.org/extensions/xep-0301.html#helping_the_recipient_stay_in_sync (I apologize -- I was going by memory) > > Note that retransmissions are OPTIONAL. (the planned addendum to > XEP-0301) > > Note that no retransmissions occur when no typing is done. (so we don't > > lose bandwidth during idle moments) > > Disclaimer: With one of my clients, I have done work to help implement > > XEP-0301 in a Next Generation 9-1-1 experimental demo, and this > > retransmission is actually added because of this paid-work experience. > > Work for NG9-1-1 is currently one of my sources of income for XEP-0301. > > > Ack. "OPTIONAL" seems like an appropriate requirement level. > In regards to "Ack" -- if you are referring to concern about potential "commercial influences" -- don't worry. I am a strong advocate of open-sourcing anyway -- my RealTimeText.java and RealTimeText.cs (C#) is released at http://code.google.com/p/realjabber/ under the Apache 2.0 source code license which allows commercial usage -- so others can benefit too. More widely-available XEP-0301 is good for accessibility reasons. There is a strong incentive to give out free source code in this case. Especially as I cannot use the telephone, and I benefit from conversational text technologies like RTT. Eventually I'll produce a good developer webpage and package my various RTT code into "libraries" for various platforms that there's demand for. In fact, I've noticed even non-deaf people love the feature (even more than video), though they need to be told about the existence of the feature. It wasn't originally an income source when I originally submitted. I initially created a deaf-friendly chat program prototype back in late 2010 that warranted XEP-0301, then I got approached after I had already submitted XEP-0301 spec. It's all good though; since it's one possible way of making XEP-0301 mainstream, and benefits the accessibility initatives long-term if XEP-0301 gets used for such an important purpose such as NG9-1-1 emergency service for the deaf. The reason why XEP-0301 hasn't been updated recently is because I've had to work on a boring non-XMPP job -- so finally getting a little bit of XEP-0301 specific income from some sources is actually a good thing, and allows me to focus more effort on improving the standard -- more time to devote to working on the Standard. > If you're going to (as you said earlier) drop the requirement of > starting at "0" this becomes more of a problem. Clients could implement > TCP-ish behaviour of starting at a random sequence number. "Arithmetic on the sequence number MUST be be performed modulo 2**32. In > particular the sequence number wraps around to 0 when incremented past > (2**32 - 1). Note that comparison of sequence numbers has to accommodate > for this fact." > Excellent point. I'll find a single sentence to insert, probably similar to your suggestion. I have to accomodate programming languages that don't support unsigned integers (Java only supports up to 2**31 for positive values), I think I'll need to make it modulo 2**31. I have to add some confusing arithmetic in order to implement proper wraparound behaviour between my RealTimeText.Java and RealTimeText.cs ... Right now, is there any way I can avoid adding wraparound logic? I have a new idea to pass by you, because I had also wanted to keep 'seq' as simple as possible. -- For <rtt> elements WITHOUT an 'event' attribute, seq MUST increment for each consecutive <rtt> element. -- For <rtt> elements WITH an 'event' attribute, seq MAY continue incrementing, or be changed to a random value. (Reusing the same seq value, such as 0, are NOT RECOMMENDED, since it results in duplicate seq values used within a short time period.) -- The seq value for an <rtt> element with an 'event' attribute, MUST be less than 2^30 (1,048,576). This reasonably prevents any potential wraparound issue (from increments) from ever occuring within a human's lifetime with integer variables in any modern programming (signed 32-bit being the worst case), and eliminates the need to program wraparound arithmetic in software clients. I'll need to convert this wording into a spec-friendly format, but what do you think of the general concept of avoiding wraparound? I eventually plan to maintain several XEP-0301 codebases, and I'd rather not have to test "wraparound math interop" between Java vs C# vs C/C++ So this is simpler, as I'm not really trying to go the "full TCP replacement" -- but a simplest possible error-recovery algorithm. > > However, yes, I agree, this is probably confusing. I am now re-wording > > things to try to clear up confusion; I will contact you later with a > draft > > wording to confirm, before submitting v0.2 of XEP-0301 to XSF. > > You are right, I confused you, so I will fix the spec to avoid that. > > > At this point I'm actually very confused. Let me quote the published > version of XEP-0301 again: > "For <d> element (Forward Delete) and all other action elements, the > cursor position is unaffected." > Ooops, I see your confusion. I apologize. What it really means: "For <d> element (Forward Delete) and all other action elements, the cursor position is unaffected *by the 'n' value.*" Which means, for <d> elements, cursor is indeed moved by the 'p' attribute, but never affected by the 'n' attribute (as it is for <e> attribute) I really sincerely apologize for my confusion -- I will fix the wording, as you have pointed out an excellent potential source of confusion in XEP-0301. Possible variant of a new simplified rewrite of the section (also accomodates removal of the <c> and <g> elements, for simplification): *Optional Remote Cursor* Implementation of cursor (caret indicator) for the incoming real-time text is OPTIONAL. Recipient clients that do not support a remote cursor, can simply ignore keeping track of a cursor position, and skip this section. All action elements always have absolute cursor positioning. When a <t>, <e>, or <d> action element is processed, the beginning of the cursor position calculation is the absolute position in attribute "p". If the "p" attribute is not specified, the cursor is put at the absolute position of the end of the message (p = length of message text). Then the next subsequent modification of the cursor position is as follows: - With <t> element (Insert Text), the cursor position (from 'p') is incremented by length of the text being inserted, putting cursor at end of inserted text. This mimics the forward cursor movement of regular insertion of text. - With <e> element (Backspace), the cursor position (from 'p') is decremented by 'n'. If 'n' is greater than 'p', then cursor position becomes 0. This mimics common cursor behaviour of a Backspace key. - With <d> element (Forward Delete), the cursor position (from 'p') is unaffected. This mimics common cursor behaviour of a Delete key. Note that the <t/> element may be empty, and in this case, only the cursor position is updated in clients that support a remote cursor (and otherwise fully ignored by clients that do not support a remote cursor). Note that <t/> without a 'p' value means the remote cursor should get put at the end of a line. Senders MAY transmit empty <t/> elements (with or without a 'p' value) whenever the sender is repositioning the cursor without any text changes. Note that a missing 'n' value for any attribute, is assumed to be a value of n='1'. Thank you for pointing out a valuable confusion that needs to be cleared up. Note -- this is actually the way RealJabber does it right now too, so it's backwards compatible with what I tried to make XEP-0301 do. (In fact, this proposed XEP-0301 "Remote Cursor" edit is apparently still compatible with old implementations including older versions of RealJabber, since now-unsupported action elements such as <c> and <g> can be safely ignored) So, maybe I just live in a to idealistic mindset, but I have severe Realistically, in real practice, it's proven beneficial for unexpectedly large number of purposes beyond those anticipated. -- Does the concept of multiple concurrent logins convince you, though? -- Does the concept of BOSH (with random HTTP errors) convince you? Nontheless, I share your ideals in generally, but I also simultaneously have to be realistic. In real-life (where it matters), I've actually found retransmits to be massively beneficial in everyday use, especially due to multiple-login. Conversation is no longer nearly as disrupted whenever I switch clients (switch computers) while the sender is still composing a real-time message, because RTT automatically resumes (since the online indicator never changes, and can't be used to trigger a retransmit). Especially if the sender is taking 1-2 minutes to finish composing and I don't want to wait for the <body> to see the RTT message. Note -- BOSH over HTTP can disconnect-reconnect many times, while making it look like a continuous XMPP session. But sometimes the web server messes up too as a separate chain of events (i.e. random HTTP failures between successes) that's unrelated to the XMPP server. Yes, I realize, theoretically it's possible to design the javascript in the web browser to buffer and retransmit failed HTTP requests (i.e. random HTTP successes, random HTTP errors, timeouts, etc), but that is not always the case, and it's often even difficult to do so with the strophe library. I promise to keep it flexible in my open source that I do now and the future -- allow retransmits to be turned off. The Apache 2.0 licensed C# module RealTimeText.cs has a configurable retransmit interval that can be turned off. (Encoder.Redundancy property = true|false) for those who want to turn off retransmit. Your comments have been good! Thanks, Mark rejhon
