On Tue, Jul 2, 2013 at 1:46 PM, Mark Rejhon <[email protected]> wrote:
> 4.7 "For implementation simplicity, recipient clients MAY track >> incoming <rtt/> elements per bare JID <[email protected]> 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
