[Standards] Proposed extension: seeing the exact text the other user is typing

Dave Cridland dave at cridland.net
Thu Nov 15 17:11:29 UTC 2007

On Thu Nov 15 15:05:13 2007, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > On Wed Nov 14 15:20:30 2007, Olivier Goffart wrote:
> >> I think this is a good approach. I think we send the text every  
> few
> >> seconds.  That would probably not be sufficient to study how  
> people
> >> talk, but sufficient for fun user experience. (and the receiving
> >> client could make appears new chars one by one, slowly)
> >> This would work fine with normal instant messaging messages (one  
> or
> >> two sentences),  but would consume lot of brandwidth very big  
> messages.
> > > FWIW, I think using this stuff over link local, or possibly  
> LAN, is one
> > thing, but using it over the internet is entirely another.
> Who are we to say what is appropriate over the Internet?
Well, we're certainly the right body of people to say something about  
it, and to draw implementor's attention to issues inherent in such a  
proposal, including Nagle's algorithm, delayed ACK, server processing  
load, and other things that affect tinygrams and µstanzas, many of  
which have been documented thoroughly in a number of places. I'm not  
going to claim we're the ultimate authority, but these are all real  
issues that will need to be either addressed, or at the very least  
noted, in any proposal.

> Look, you have a given swath of bandwidth.

(I'm not sure swath, or swathe, is the right word here. But anyway. A  
given width of band?)

>  If you use it to send
> char-by-char text, that may be fine depending on the context.

Yes, I'm just saying that char-by-char text has issues which are much  
more significant when used over the Internet, and that needs to be  
factored into the context.

>  Example:
> you have set up a special text-only helpline and you need to know
> exactly what text people type so that you know if the person typed  
> "he
> has a knife, I think he's going to kill me" instead of receiving a
> XEP-0085 <composing/> indicator and then <gone/>.
I'm struggling with the validity of this use-case. But see below for  
a better solution. (And yes, I can think of very rare, convoluted,  
use-cases where this makes sense).

> I agree that char-by-char text is not generally a good idea (or even
> desirable to the vast majority of users), but in certain situations  
> it
> might be very useful indeed.

Sure, although I suspect this is a solution searching for a problem.  
I think at the end of the day, some people find this kind of thing  
fun - that's reason enough to consider standardizing, but caveat  

FWIW, I think an extension for sending partial messages makes more  
sense than aiming to get char-by-char messages. Sending the partial  
messages when the user has *not* been typing for a while makes more  
sense to me than sending while the user is still actively using the  
keyboard. This could be negotiated down to effectively char-by-char  
over particularly short wide links, such as link-local, but be more  
network-friendly over the Internet.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list