Protocol Plugin Development Problem - Status Types

[Ralf Kistner]

How does the comparison work then? Both MXit and XMPP use the same status 
types, so it should be possible (the only difference is the attributes).

I would expect it to included the status if both protocols support the same 
status type, e.g. PURPLE_STATUS_EXTENDED_AWAY. This seems like a simple check 
to do (for each status type, check if all the protocols support it). A 
problem might be though that a protocol may have multiple statuses using the 
same Purple type (e.g. PURPLE_STATUS_AVAILABLE is used for both "Available" 
and "Chatty" in XMPP)... which one is chosen then?. How is this chosen if the 
default list is used?

Ralf

On Saturday 24 November 2007, you wrote:
> On Nov 24, 2007 6:13 AM, Ralf Kistner <ralfgm at gmail.com> wrote:
> 
> > I'm busy developing a plugin for the MXit protocol (www.mxit.co.za). At
> > the moment I'm stuck with a small problem with status types.
> >
> > The protocol uses the same status types as XMPP:
> > - Available
> > - Chatty
> > - Away
> > - Extended away
> > - Do Not Disturb
> > - Offline
> >
> > In my test setup, I have two accounts: one MXit and one XMPP. When I have
> > either one enabled, the status types work fine.
> >
> > However, when I have both accounts enabled at the same time, I can only
> > set my status to one of the following:
> >
> > - Available
> > - Away
> > - Do not disturb (case changes)
> > - Invisible (where does this come from?)
> > - Offline
> >
> > "Chatty" and "Extended Away" are missing. Why this change when I enable
> > both accounts?
> >
> 
> The way that the statusbox works is that if the only accounts enabled are
> using the same protocol *and* have the same statuses available do all the
> account statuses appear in the list, otherwise you see the default list
> above.
> 
> The way the comparison works, it doesn't try to use the lowest common subset
> of statuses because it really doesn't know that the statuses are necessarily
> equivalent across multiple protocols (although the argument could be made
> that it could try harder to do so).  This would get significantly more
> complicated and might cause unexpected behavior - Do you match on the name?
> What if the names are the same, but some other part of the status is
> different?
> 
> -D
>