Re{factor,write} of status API

[Paul Aurich]

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.

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).

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).

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.  :)

~Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110627/63296e5e/attachment.sig>