[Standards] 301 feedback

Christian Vogler christian.vogler at gallaudet.edu
Tue Jul 2 18:08:22 UTC 2013


I agree with Mark re the bare JID. It seems to be simpler from both a
user's point of view and an implementer's perspective. The logic can be
seen in line 1252 at
https://github.com/cvogler/trophyjs/blob/master/trophy.js

- all it does is to check whether a RTT message is in sync by both checking
expected sequence number and last seen full JID. If either exhibit a
mismatch, it is treated as an out of sync condition with normal recovery
procedures. All subsequent dispatch of that message is by bare JID.

Christian

Sent from my mobile phone.  Please excuse any touchscreen-induced weirdness.
On Jul 2, 2013 1:57 PM, "Mark Rejhon" <markybox at gmail.com> wrote:

> 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/cf00a23e/attachment.html>


More information about the Standards mailing list