On Mon, Feb 28, 2011 at 8:52 PM, Mark Rejhon <[email protected]> wrote:
> With the help of others at realtimetext.org, I will take the
> opportunity to rewrite portions of the standard to bring it into
> better compliance with XMPP.org. I am currently collaborating behind
> the scenes with realtimetext.org at this time. I also have open
> source code I am releasing shortly (goal: end of March), which will
> help demonstrate the proposed specification. This may help you all to
> determine what features are necessary, and what features are
> unnecessary.
Great.
> In regards to some of the ballpark 'concerns':
> 1) Simplifying the specification
> Up front, there are a lot of things that I could simplify in the
> standard to reduce word count dramatically, perhaps by as much as
> about 40%. Removing redundant/duplicate information, unnecessary
> fluff content, rewording certain parts into more clear English,
> remove some unnecessary requirements, remove less important features
> such as Group Chat, etc. I will work with the people of
> realtimetext.org on this.
I think this is worthwhile.
> 2) Complexity introduced by Delay Codes (Natural Typing)
> Originally, I was going to make this a private feature of my own
> implementation (i.e. private extension). However, testing indicated
> rave reviews.
This is somewhat counter-intuitive, as if network latency is
consistent, the edits will arrive at a similar sort of rate to that at
which they were transmitted and if it's not consistent, the edits are
unlikely to arrive in a timely manner. I have a suspicion that what's
happening here isn't the use of the delays that make the transmission
delays less noticeable, but rather that the act of rendering the new
text slowly is itself masking network latency. I wonder if there's a
substantial difference in user experience between using the latency
encoding on realtime edits, and simply using fragments, but having the
client render e.g. n changes a second.
> 3) Complexity introduced by Real Time Message Editing Protocol
> - Real time message does complicate the standard. However, it is a
> necessary inclusion for reasons already explained.
Compared with some simpler typing transmission system, or compared
with whole-message only?
> - Technically, we could simply retransmit the whole message, which is
> also allowed by the standard (Section 3.9.3). However, this is
> inefficient for long lines of messages,
I'm not entirely convinced about this (I think stream compression
should be smoothing out a lot of these data unless the messages get
*really* big.
> and makes it difficult to
> serialize the real time message editing protocol.
I don't think this is true - XMPP already guarantees in-order
delivery, so this spec shouldn't have to deal with that.
> - Cursor movements are included because it makes it much easier to
> watch the remote person edit their real time text -- otherwise, edits
> to the middle of their message sometimes went unnoticed more often by
> the recipient (and lead to more misunderstandings due to missed
> edits).
Surely that's a client rendering issue, though?
> - Delay codes for inter-keypress delays are good because typing looks
> natural (and does not 'burst'), irregardless of the interval. Testing
> shows that this is a highly desirable extension to the spec. See
> next section below.
> - It is noted that both of these features are NOT made 'REQUIRED'
No, but they're (from memory) SHOULD, which is as near as.
> - Testing of the open source software clearly showed that highest
> quality of real time text occured when I included support for delay
> codes and cursor positioning.
> -- The open source software that's being released soon, has an
> adjustable interval, and allows turning on/off features (including
> delay codes and cursor codes), so that you can all judge how
> necessary/unnecessary individual features are.
I'd be interested, if it allows complete retransmit with fake-delay
rendering, to see how significant the difference between this and the
full suite is.
> 4) Programming complexity
> I realize the comment about programming simplicity is relative and
> subject to interpretation. I got the first version of the real time
> text working in less than 2 days, in an initial round of programming
> utilizing the open-source jabber-net library. If I excluded the
> optional cursor movements and delay codes, I actually found it really
> simple to include real time message editing. I had found most of the
> complexity is actually found in the delay codes, as well as how I
> prepared the messages for transmission. Even with those advanced
> features thrown in, I had a module (specifically for real time text)
> that was still only 800 lines of code. If you ignore all the
> RECOMMENDED's and OPTIONAL's, the standard is actually much simpler to
> implement and actually could be crammed into a much smaller document.
If these things can be safely ignored, then they should be OPTIONAL,
rather than SHOULD.
> Perhaps the standard should clearly separate the features so that the
> easy features are in a separate section from the advanced features, so
> that it's easier for implementors to do a baseline version of this
> spec. Part of the reason why the specification looks more complex
> than necessary because the easy and hard parts are interspersed with
> each other. By releasing open source code, it will help people
> understand how easy or complex the specification is.
Certainly, if there are two different models, one easy, one hard, we
should make it as easy as possible to implement the easy one. I still
have doubts about the need for anything difficult - this is why
Council (or I, anyway) seek community feedback on the spec.
> 5) Rationale of Attributes ('seq', 'msg', and 'type')
> I found it necessary to include these attributes, because of the
> nature of real time message editing. If a message gets lost, and the
> message contained an edit (i.e. an insert/delete in the middle of
> text became lost), then subsequent edits are invalid -- message length
> is different, so a subsequent edit won't occur in the correct
> location, and the text will become mangled. Therefore, perfect
> integrity is needed in subsequent real time message edit operations,
> using some sort of continuity mechanism (sequence ID) or other sync
> verification method. There was experimentation done with the
> open-source software that showed the 'seq' was necessary, as was a
> method of signalling the first received real time text message
> (type='new').
I'm surprised you found missing messages a significant problem, but
maybe this is necessary.
/K
