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

[immerrr again]

Please, see the answers inline.

On Tue, Apr 9, 2013 at 11:35 AM, Mark Doliner <mark at kingant.net> wrote:
>
> 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.

Which is exactly why I've agreed that it's better to do as a plugin
rather than to alter libpurple's default behaviour.

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

I have doubts about automatic detection because -- see my use case in
original message -- hdd spin-ups & powersaving is only one side of the
problem, generated inotify events may also be undesirable per se.

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

Which is exactly why "void* arg" is there as a last parameter. It
could be any information concerning the event including the name of
setting being modified or the "importance" metric as described in your
message or both or anything else, I had intentionally omitted the
details to avoid diving into premature design issues, but the idea was
to provide _all_ the information necessary to reason about how and
when to save the change to a plugin and let it do its job.

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

On one hand, yes, that's a perfectly valid point. But, like I said,
the fix _for me_ is a one-liner and it will only take one more hg
repository and one more PPA to set up to have a properly packaged
pidgin for all of my Ubuntu workstations. So I'd rather this general
solution wound down during discussion than put aside upon
implementation due to insurmountable issues in backporting.

--
Cheers,
immerrr