Re: [Stox] chat states <-> isComposing

[Saúl Ibarra Corretgé <[e-mail]>]

Hi Peter!

Thanks for looking into this, I think it's really useful.

On Sep 18, 2013, at 5:10 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've taken a look at the mapping between XMPP chat states (XEP-0085)
> and the isComposing event (RFC 3994).
> 
> RFC 3994 has two states: idle and active. RFC 3994 has only two states
> because it's really just about composing (in messaging, whether or not
> the sender is actively typing or otherwise creating text for sending
> to the recipient -- simply toggling between the two, changing to
> active if the user is composing a message and changing to idle when
> not composing a message).
> 
> XEP-0085 has five states: active, inactive, gone, composing, and
> paused. XEP-0085 has more states than RFC 3994 because it's not just
> about composing, but about the sender's involvement with the chat
> session. Thus in XEP-0085, "active" means "paying attention to the
> conversation", which ironically maps best to RFC 3994 "idle", I think.
> 
> It might be best if we don't map XEP-0085 chat states other than
> composing and paused to RFC 3994 isComposing events, since RFC 3994 is
> just about composing. However, in XEP-0085 it is possible to have
> state transitions such as composing to active (not paused).
> 
> Thus the safest mapping might be
> 
> isComposing => chat states
>  idle => active
>  active => composing
> 

Yes, I implemented this mapping following my intuition and feels ok in actual usage.

> chat states => isComposing
>  active => idle
>  inactive => idle
>  gone => ???
>  composing => active
>  paused => idle
> 

Here comes the dilemma: that gone state. Not many clients implement the 'gone' state, but those who do tend to render a message such as "Peter left the conversation" if they get one, and likewise, send it if you close the conversation tab. Based on this non-scientific testing I mapped it to a SIP BYE, both ways. That is, if we are having a chat session (I am on MSRP and you on XMPP) if I end the SIP session, the gateway would send a gone chatstate, and if your client would send it, the gateway would terminate the SIP session.

I know this looks weird, since we are mixing payload translation with session management, but since the gateway needs to handle all chat media I don't see a problem with that.

Thoughts?

> This mapping loses some of the granularity on the XMPP side (i.e., the
> paused and inactive states), but that might be fine in this context.
> 

We'll need to adjust to the minimum common denominator, like we do in groupchat :-)


Cheers,

--
Saúl Ibarra Corretgé
AG Projects