[Standards] 301 feedback

Mark Rejhon markybox at gmail.com
Tue Jul 2 17:57:15 UTC 2013


On Tue, Jul 2, 2013 at 1:46 PM, Mark Rejhon <markybox at gmail.com> wrote:

> 4.7 "For implementation simplicity, recipient clients MAY track
>> incoming <rtt/> elements per bare JID <localpart at domain.tld> to keep
>> only one real-time message per sender"
>> Would this really help implementors? Trying to do bare-JID only seems
>> like it's going to involve more complexity and headache than doing
>> full-JID.
>>
>
> To the contrary; you would be surprised that this actually simplifies
> things.  Since all implementers are REQUIRED to implement other parts of
> section 4.7 "Keeping Real-Time Text Synchronized" (for other reasons), this
> de-facto makes bare JID processing _much_ simpler than full JID processing
> because:
> -- Your software only need to keep track of one real-time buffer per window
> -- Your software user interface only needs to dispolay one real-time
> message per window.
> -- It's accidentally more intuitive anyway (we don't expect multiple
> typists from the same JID).
> No other software changes because other REQUIRED elements of XEP-0301
> automatically handles (or even by one interpretation, "by accident")
> bare-JID processing.
>
> Example use case, which can be done solely using web browser:
> 1. Get three laptops/computers/ipads/tablets. (or three separate brands of
> browsers on same computer -- Mozilla, Chrome, IE)
> 2. Load http://tap.gallaudet.edu/rtt/ on all three
> 3. Log on using one JID on one system.  This is system "A"
> 4. Log on using different JID on two systems.  This is system "B1" and "B2"
> 5. Start playing with messaging each other.
> 6. Start typing on A.  You'll see your real-time text show on both B1 and
> B2.
> 7. Start typing on B1.  You'll see your real-time text show on A.  Hit
> Enter before the next step.
> 8. Start typing on B2.  You'll see your real-time text show on A.  Hit
> Enter before the next step.
> 9. (TEST OF BARE JID PROCESSING)
> Start typing on B1 and then stop typing without hitting Enter.  Real-time
> text shows on A.
> Now start typing on B2.  Real-time text is frozen on A (because it's
> required anyway), for up to about ~10 seconds (thanks to section 4.7.3),
> then the whole message gracefully suddenly switches from the B1 partial
> message to the B2 active message.  You'll quickly see that the behaviour is
> quite intuitive.
>
> Both RealJabber and the TAP client use bare-JID processing for simplicity
> (one real-time buffer per window)
>

Now from the end-user's point of view, the equivalent situation occurs:

1. User (logged simultaneously on B1 and B2) is typing a message on B1
(e.g. a desktop)
2. User steps away without hitting Enter.
3. User picks up B2 (e.g. a tablet) and starts typing a message.
4. The person at A will eventually start seeing real-time text from B2
instead of B1.

So this is the common use case: Device-switching (without first committing
message).
There is typically only one user logged onto all the JID's, and it would be
a very rare case that people are typing from multiple clients under the
same JID, too.

-- If the client only supports bare JID, the RTT message from B2 simply
eventually replaces the RTT message from B1.
-- If we did multi-JID handling, we'd see multiple RTT messages (a stalled
B1 message that's persistent on-screen, and an active B2 message).
-- There are definitely pros/cons of the two above approaches, but on
average, the bare JID handling tended to be more intuitive (user
perspective) and simpler (developer perspective) as the developer is forced
to implement other REQUIRED aspects of XEP-0301 for other, different
reasons, but which happens to makes bare JID processing the simple choice
since no other work is required to support bare JID processing.

NOTE: If the user went back to B1 and resumed typing the message, it will
replace again (switch back), or if the user already commited B2 by hitting
Enter, the B1 message will automatically show up as a new real-time
message, thanks to the first bullet in "4.3 Processing Rules".

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130702/0dbb7b65/attachment.html>


More information about the Standards mailing list