Re{factor,write} of status API

[Jan Kaluza]

On Tue, Jun 28, 2011 at 5:08 AM, Paul Aurich <paul at darkrain42.org> wrote:
> With next.major on the table, and Jan Kaluza (HanzZ) having brought this up
> a few weeks ago, I thought I'd open up the table to some discussion about
> what to do with the current status API.

Thanks for starting this discussion :).

> The current state is a bit dismal when it comes to usability (tricky mental
> model, very verbose API, etc), though it does generally work (once you
> figure it out...or find the savedstatus API).

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'm assuming everyone would be open to rewriting/simplifying it for 3.0.0.
>
> 1) What things do you want to keep?
> 2) What things do you want to lose (other than as large a percentage of the
> exposed API as we can)?
> 3) Any suggestions about a possible architecture?
>
> Regarding #3, one thing I'd like to see is a single (exclusive)
> "PurpleStatus" per buddy/account.  Each time the status changes, a new
> PurpleStatus should be instantiated; this way, status-changed events have
> both a "old_status" and "new_status" object, which aren't the *same stupid
> object* (see #4696).

I want to have just one exclusive PurpleStatus per PurplePresence and then
optionally another non-exclusive statusescreated/removed on prpl's demand.
This is partly implemented in my patch (status removal part is missing).

I share the idea to always instantiate new PurpleStatus object, inform UI with
old_status and new_status and then remove old_status.

The problem here is that nothing (plugins/UIs/prpls) expect that PurpleStatus
can be removed in the PurpleBuddy/PurplePresence life-cycle which could be
problem for 3rd party plugins or prpls (although I haven't checked any yet).

> This would also cut down on the at-buddy-instantiation time allocations,
> which was Jan's hope.
>
> Furthermore, I don't think we *really* need to keep the "default" values
> for each status (these are used when changing status to reset all the
> unspecified attributes to their default values) allocated once per buddy
> (surely once per account is good enough?).  I'll caveat the prior sentence
> by saying that I *think* it's correct these are stored per-account, but I
> can't actually reverse engineer the hackery I did for the XMPP prio plugin
> (http://hg.guifications.org/purple-plugin-pack/file/87484177eba0/xmppprio/xmppprio.c)
> a few years back.
>
> Jan, thanks for keeping after me to bring this up.  :)

Thanks for your time, too. :)

> ~Paul
>
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
>

Jan Kaluza