[standards-jig] LAST CALL: JEP-0085 (Chat State Notifications)

Sebastiaan Deckers cbas at rhymbox.com
Wed Jan 14 22:40:23 UTC 2004


Nathan Walp wrote:

>I won't comment on how good or bad an idea it is to replace 0022 with
>0085.  I haven't decided yet.  However, if 0085 is to be accepted,
>consider the following:
>
>"Romeo realizes his reply is too rash and pauses to choose the right
>words; after some (configurable) time period, his Jabber client senses
>the delay and reverts to a state of Active."
>
>As long as we're making new protocols, is there any objection to adding
>a separate state for this event?  I guess "Paused" would be a good name
>for it.   The state chart would look something like:
>
>                  o (start)
>                  |
>                  |
>INACTIVE <----> ACTIVE <----> COMPOSING <----> PAUSED
>    |             |              |               |
>    |             |              |               |
>    |             |              |               |
>    +---------> GONE <-----------+---------------+
>                  |
>                  |
>                  o (end)
>
>AIM chats have a similar state, for when the user has typed something,
>but paused.
>  
>

Hello,

While I do not oppose the idea of explicitly adding the PAUSED state to 
the specification, I would like to point out that the described scenario 
can also be achieved by extra logic in the recipient's client.
The PAUSED state is nothing more than an ACTIVE state received after a 
COMPOSING state has been received, but before the next message or 
COMPOSING/INACTIVE has been received.

Example:
 0. Juliet has not received any chatstatus from Romeo
 1. Juliet receives a message with the ACTIVE chatstate attached
 2. Romeo starts composing a new message
    -> Romeo's client sends the COMPOSING state
    -> Juliet's client shows that Romeo is composing a new message
 3. Romeo pauses
    -> Romeo's client sends the ACTIVE state
    -> Juliet's client shows that Romeo has PAUSED
4a. Romeo decides to send the message anyway
    -> Romeo's client adds the ACTIVE state to his message
    -> Juliet's client returns to step 1
4b. Romeo re-composes his message
    -> Romeo's client sends the COMPOSING state
    -> Juliet's client returns to step 2
4c. Romeo decides he has nothing to say and closes the window
    -> Romeo's client sends the INACTIVE state
    -> Juliet's client returns to step 0

One advantage to the explicit PAUSED state would be that Romeo's client 
can announce a difference between ACTIVE-as-in-PAUSED and 
ACTIVE-but-not-PAUSED.

Just a quick back-of-the-napkin idea.

Regards,
Sebastiaan




More information about the Standards mailing list