Typing notifications have problems.

[anonymous]

On bitlbee 20051202, on AIM, here's how typing notifications are used:

Remote user starts typing: bitlbee sends (ctcp) TYPING 1 Remote user pauses typing, with text still entered (stale, see ticket #42): bitlbee sends TYPING 1 Remote user backspaces _everything_, bitlbee sends nothing.

So, if you're writing a script to interpret these, there are a couple of ways you can approach it:

1) Use timeouts to determine whether the user is still typing or has stopped typing.

Problem 1: This may inappropriately remove the typing notification if the user types longer than your timeout.

Problem 2: If the user enters a stale typing state, the script will interpret this as if the user is still typing (which they really will not be, since they paused typing). But, on MSN, an additional TYPING 1 message means the user is still typing, because on MSN, timeouts are used.

2) Interpet additional TYPING 1 messages as indications of a stale state

Problem 1: Since no timeouts are used in this method, if a user backspaces everything, and nothing is sent by bitlbee, the script thinks the user is still typing, and will continue thinking this until the user types again, at which point bitlbee sends another TYPING 1 ctcp, which will cause the script to believe the user has entered a stale state and removes the typing notification. This is bad.

Problem 2: On MSN, the typing notification will alternate between being on and off. Bitlbee will send an additional TYPING 1 message every 5 or 6 seconds to indicate the user is still typing, and the script will interpret every even notification as the indication of a stale state, and remove the notification. A solution, on the script side of this, would be to check if the remote user is on MSN or AIM, and interpret additional TYPING 1 messages accordingly by setting stale or keeping the notice up. But, this solution will not fix the problem over AIM regarding what happens if the user backspaces all of his or her message.

Proposed solution (to fix both MSN and AIM):

Have bitlbee send TYPING 0 if the user has stopped typing, TYPING 1 if the user has started typing or started typing *again* (back from a stale state) or is still typing (though this may be unnecessary). And finally, send TYPING 2 if the user has entered a stale state. As mentioned above, stale states on AIM are currently indicated by an additional an TYPING 1 message, which conflicts with MSN.

This ticket should supersede my previous ticket (#42).

[wilmer]

I'll apply this one soon. But from what I see in the channel it's going to be hard to get things to work for every protocol. *sigh*

Removing MSN from the keywords list since AFAIK that's actually the only protocol on which they do work well. :-)

[f0rked <root@…>]

OSCAR supports stale states. Yahoo is similar to OSCAR in the way it works, except it does not support the stale status, it just sends TYPING 1 or TYPING 0. MSN only sends TYPING 1 and timeouts are needed to determine whether the user has stopped typing.

The patch should make the notifications unambiguous by sending TYPING 1 only when the user is actually typing, for all protocols. TYPING 0 will be sent over OSCAR and YAHOO connections when the user is not typing, so timeouts should not be used for these protocols. TYPING 2 will be sent over OSCAR when the user has stopped typing but still has text entered. MSN was not touched except to add another argument to the function call.

After the patch, bitlbee should send the correct typing messages for OSCAR, Yahoo, and MSN. I've been running the fix for a day or two and have experienced no problems.

Unfortunately, stale states aren't yet supported from the bitlbee user's end (sending /ctcp somenick TYPING 2 will not do anything).

[wilmer]

[77] \o/