Regarding XEP-0301 -- http://www.xmpp.org/extensions/xep-0301.html Totally agree with the vast majority of Gunnar's answers. Just some very minor tweaks needed.
On Sun, Jul 7, 2013 at 1:31 PM, Gunnar Hellstrom < [email protected]> wrote: > ADD just before table: > For consistency, the text may need to be added afterwards the table (other parts of XEP-0301 put such table-describing text afterwards) > COMMENT #4 > 4.7 "Alternatively, recipient clients MAY keep track of separate real-time > messages > per full JID > <[email protected]/resource><[email protected]/resource>and/or per > <thread/> (Best Practices for Message Threads [9])." > I think that some of the earlier instructions will be incompatible with > having multiple RTT messages per full-JID. > It would be worth someone else checking. > > ANSWER #4 > The sentence may be confusing, it is only when multiple threads are used > that multiple real-time messages > per full JID are needed. > > CHANGE: "Alternatively, recipient clients MAY keep track of separate > real-time messages > per full JID > <[email protected]/resource><[email protected]/resource>and/or per > <thread/> (Best Practices for Message Threads [9])." > > INTO: "Alternatively, recipient clients MAY keep track of one real-time > message per full JID > <[email protected]/resource><[email protected]/resource>or > one per full JID and thread if threads are used. See (Best Practices for > Message Threads [9])." > Let's discuss this a bit further with Kevin: This type of wording change may not be sufficient. There are these theoretical situations: 1. bare JID handling, ignoring <thread/> (execting 4.7 out-of-sync handling on any collisions) 2. bare JID handling, interpreting <thread/> (execting 4.7 out-of-sync handling on conflicting full JID's) 3. full JID handling, ignoring <thread/> (execting 4.7 out-of-sync handling on conflicting <threads/>) 4. full JID handling, separate <thread/> XEP-0301 would work fine with all the above scenarios. The user experience would vary, but none of the scenarios would make XEP-0301 unusuable because, in principle, there's typically only one typist coming from bare JID. The major usability divergences do begins to occur when multiple typists start to use the same account (e.g. a wife and a spouse sharing the same Jabber login). In this event, the out-of-sync handling behaviour differences become apparent (Simple worst case scenario: Thrashing of real-time text from one buffer to the other buffer in a once-every-10-second cycle, in the rare situation of simultaneous typists. But when hitting Enter, the two separate messages will still successfully be delivered) Now, as both me and Chris has expressed that we should leave it to the implementer to decide how it handled -- e.g. decide on what handling to do that allows simplification of implementation to just "one-real-time-buffer-per-chat" -- then I would prefer it that way, as typical scenario (>99% of use cases) is one active typist per bare JID (e.g. simply switching between devices) and all 1/2/3/4 works just fine in that scenario in a very interoperable manner; it's mostly a UX variance. The implementor does not have to merge window handling and real-time-message-buffer handling, but the option is easily there, if the implementer shall choose to do so; to simplify & improve UX. Obviously, MUC would require support for multiple real time message buffers per window, and thus would make it fairly easy to handle (4). But not all clients want to support MUC, and thus would be quite a lot simpler (multiple implementers agree with me) for such clients to just follow (1). As a result, I want to word things in a way that allows the implementer to decide what is easiest; Thanks! Mark Rejhon
