Feature: don't autosave blist.xml upon "last_seen" changes

[Mark Doliner]

This is going to be complicated.  Delaying the write of blist.xml WILL
result in some people losing information (if Pidgin or their computer
crashes).  Losing the last_seen timestamp is not really important, of
course, but losing something like a buddy alias change would be
frustrating.

My initial reaction is that most users won't benefit from this change,
and so whatever changes are made should be isolated so as not to hurt
the majority of users.

I think the ideal solution would somehow know whether the user was on
a battery powered device and be smart enough to delay writes.  Or
detect whether the hard drive is asleep and delay until the next time
the hard drive wakes up.

On Mon, Apr 1, 2013 at 12:35 AM, immerrr again <immerrr at gmail.com> wrote:
> On Sat, Mar 30, 2013 at 3:08 PM, Peter Lawler <bleeter at gmail.com> wrote:
>     typedef enum {
>        PURPLE_BLIST_NODE_INVALID_REASON = -1,
>        PURPLE_BLIST_NODE_CREATE,
>        PURPLE_BLIST_NODE_CHANGE_SETTING,
>        PURPLE_BLIST_NODE_RENAME,
>        PURPLE_BLIST_NODE_REMOVE
>     } PurpleBlistNodeSaveReason;
>
>     void
>     purple_blist_save_node_with_reason(PurpleBlistNode *node,
> PurpleBlistNodeSaveReason reason, void* arg);

I think these reasons aren't good for deciding whether to write the
blist to disk.  One PURPLE_BLIST_NODE_REMOVE might be extremely
important while another might be insignificant.  I think a better
solution would be to give an importance value to change.  An updated
last_seen timestamp could have an importance value of 1, while
changing a buddy's alias could have an importance value of 50.
libpurple could write the blist to disk if the cumulative importance
of changes since the last write is >=100.  You could also possibly
save the blist if N minutes have passed and the cumulative importance
is between 1 and 99.

> Well, I'm not really sure where to find the guidelines in writing
> plugins/GUIs for libpurple, so but something tells me that this might
> open a pandora box of backward incompatibility (especially, ABI
> incompatibility) issues when a plugin (or a GUI) is oblivious of the
> new API.

I suggest you not constrain your solution based on ABI compatibility.
If a clean solution requires breaking the ABI, so be it.  Figuring out
how to backport the change to not break ABI should be an afterthought.