Re{factor,write} of status API

Jan Kaluza hanzz.k at
Wed Jun 29 04:44:53 EDT 2011

On Wed, Jun 29, 2011 at 2:21 AM, John Bailey <rekkanoryo at> wrote:
> On 06/28/2011 01:44 AM, Jan Kaluza wrote:
>> My biggest problem with current status API is that every PurplePresence contains
>> PurpleStatus for *all* status_types supported by prpl, which is big
>> waste of memory
>> (see stats in #14290).
>> I have "fixed" that in #14290 and I believe future changes can be
>> based on that patch,
>> but I don't mind if they won't.
> I have a better idea.  Let's axe PurplePresence.  As I see it, its existence
> does nothing but serve to complicate and confuse matters.

The true is that PurplePresence is just "container for
PurpleStatuses", but I'm not sure if removing it is good idea. You
would have to move "idle/login_time/idle_time" and other things (even
GList *statuses and active_status pointer) somewhere.

The only place I see is moving it upstream (into

This way you duplicate stuff and you have to manage everything
separately (basically reimplement most of purple_presence_* functions
in PurpleAccount/PurpleConversation/PurpleBuddy).

Maybe I just don't see they way you do, so please correct me. So far I
find this abstraction useful (although little bit complicated to

>> I share the idea to always instantiate new PurpleStatus object, inform UI with
>> old_status and new_status and then remove old_status.
> I've wanted this basically since 2.0.0.  This would enable the buddy state
> notification plugin to have some additional (optional) functionality--it could
> tell you whether the user went away, came back, etc.

Little off-topic, but is there anything special I have to do to create
branch for this changes or just reading monotone documentation and
finally installing monotone and creating the branch is enough?

> John
> _______________________________________________
> Devel mailing list
> Devel at

Jan Kaluza

More information about the Devel mailing list