Custom Query (1098 matches)

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).

as seen in the msn patch (listed on the bitlbee mainpage as link) who has you on there buddylist and isn't on yours and vice versa (emonicon receiving/sending and photo recieving/seinding isn't interresting)

my system: bitlbee 1.0 + akke patch (for 0.92) debian 2.4 kernel

my story: i just talked to someone at MSN, and she left the converstion (has setup hidden mode). i got 'MSN - Error: MSN: Error reported by switchboard server: Person is off-line or non-existent' message. after she come back i was able to write to the conversation but she has not seen my messages.

wilmer's opinion: <wilmer> but yeah, reproduced the bug

dy