[Standards] XEP-0301 0.5 comments [Clarification about Client Switching / Single JID Handling]
markybox at gmail.com
Wed Jul 25 16:01:03 UTC 2012
On Wed, Jul 25, 2012 at 6:21 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
> > Also, it is intuitive behaviour because of "Keeping Real-Time Text
> > Synchronized" so a simultaneous login user switching computers, the
> > recipient would simply see their copy of the real-time message switch
> > instantly from the partially-composed message from the old system to the
> > partially-composed message from the active system.
> This doesn't seem likely, does it? Shutting down one computer where
> you were typing, booting up another computer and the text you were in
> the middle of composing being there ready for you? And if someone did
> implement this, they could just send a reset?
There's no logging off involved -- They keep running simultaneous.
Due to the misunderstanding, I feel I might need to explain this better in
the spec -- perhaps we can discuss how to improve the wording in the spec
to be clear, because:
This is common use case:
- Person switches from PC to laptop.
- Person switches from Mac to iPad
- Person switches from Android to PC
They keep the clients running at the same time.
Single JID works even when they are all logged on, thanks to the "Keeping
Real-Time Text Synchronized".
This is what happens:
1. Sender is running a client simultaneously on PC and laptop. Actively
2. Sender starts typing a message on PC. (Example: "Hey! Want to go for")
3. Recipient client processes by single JID, receives <rtt/> normally.
4. Recipient sees real-time text "Hey! Wants to go for" but suddenly stops
5. Sender switches to laptop (e.g. interrupted by phone call, remembers
6. Sender begins typing a message on laptop (Example: "Management just
7. Within 10 seconds, Recipient client replaces "Hey! Want to go for" with
"Management just ")
...."Behind The Scenes" (logic in the software following "Keeping Real-Time
..........Single JID workflow:
..........Recipient client processing by single JID detects conflicting
<rtt/> (sections 4.6.1 and 4.6.2)
..........Recipient client pauses "Hey! Want to go for" (section 4.6.2)
while waiting for recovery (ignoring conflicting <rtt/>)
..........Sender client sends a Message Reset (section 4.6.3) within 10
..........Recipient clients goes back in sync (section 4.6.2) and
redisplays message, from correct sending client
..........Recipient client now displays "Management just " in place of
"Hey! Want to go for".
8. Sender still continues typing. Message is now "Management just
9. Recipient sees normal real-time text, now that the message is back in
10. Note that the original unattended sender PC still has a
partially-composed "Hey! Want to go for" but it's not transmitting
anything, because no text changes are taking place. (This is already
mentioned a couple times in the spec that you shouldn't transmit <rtt/> if
the message is idle, but I can mention this fact again if it's not clear)
So you see, it works, even with just "bare JID" handling.
The sender can send full JID, but simplest implementations of clients only
need to keep track by bare JID for simplicity.
Thanks to "Keeping Real-Time Text Synchronized", it works.
Therefore, the recipient clients really only need to internally keep one
copy of real-time message per bare JID
Note: The user can even switch back to the original PC, too!
11. Sender switches back to the original PC after the management p hone
12. Sender resumes typing on PC (which still has "Hey! Want to go for")
12. Sender now has "Hey! Want to go for dinner with the family?"
13. Within 10 seconds, recipient client replaces real-time message
"Management just called....Hang on." to "Hey! Want to go for dinner with
.......Behind the scenes is the same as #7 above
14. Real-time text is continuing normally.
There is NO logging off required.
People often keep their Google Talk running all the time on their mobile
This is a very common scenario
-- switching PC to laptop
-- switching from iphone to laptop
-- switching from Mac to iPad
-- switching from Android to PC
-- switching from PC to android
-- even 3 or 4 devices logged on, switching from PC to laptop to iPhone
You can log on, log off, or keep all logged on -- all possible switch
scenarios are taken into account.
NOTE: More than 99%+ of the time, a sending JID only has one active typist,
even with simultaneous logins, so this is quite acceptable behaviour in our
field testing. It's quite a good user experience in actual field tests.
There could be situations such somebody else (such as a daughter/son
walking up to the sender's other computer) and typing simultaneously under
the same JID. This simply cause occasional flashing back and forth of the
full contents of the message being composed on one system, and message
being composd on the other system, until one typist stops -- then the
recipient is seeing stable real-time text even with just recipient-side
bare JID processing (keeping track of only one real-time message per chat
window). (Note: Implementations can detect thrash behavior with some
smart logic, logic combined with XEP-0296 Resource Locking behaviours, etc.
and wait longer, or do very, very rudimentary full-JID checking (while
continuing to internally keep only one real-time message) in order to wait
until <rtt/> is coming from only one sending client for at least a few
seconds, before displaying the real-time message). All these
implementation-specific behaviours are all beyond the scope of XEP-0301.
What is important is that computer-switching works great and seamlessly, in
test trials, in nearly all possible client-switching situations, including
all the common scenarios.
Since some people are confused about how "Keeping Real-Time Text
Synchronized" (which is useful for many other situations other than this),
also benefits the ability to allow simpler recipient implementation --
keeping track of one real-time message per JID.
Yes, it's valid behaviour for recipients to keep track of multiple
real-time messages, but that's an implementation detail.
But it's equally valid for recipients to just keep track of a single
real-time message, for simplicity.
I am welcoming suggestions on improving wording on specification, to make
this very clear, that it is acceptable for basic implementations in
recipients, for simplicity, to process real-time messages based on bare
JID, even if senders use full JID when sending real-time messages.
Should I even be mentioning UX (user experience) details, such as what I
described above? I have been told to avoid describing UX details.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards