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

[Phil Hannent]

Good morning,

I was reading over this last night, in the blist.c there is already a 5
second delay:

Line 401:
https://hg.pidgin.im/pidgin/main/file/0ab9ed685a54/libpurple/blist.c

When the blist uninit's it will force a sync of course. So if the program
terminates correctly there should never be data loss. That delay could be
extended if libpurple detects that it is running on battery, which
according to a quick search can be determined by looking at:

/sys/class/power_supply/BAT1/present
/sys/class/power_supply/BAT1/status

Regards
Phil Hannent



On 9 April 2013 08:35, 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.
>
> 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.
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130409/eaaee3fa/attachment-0002.html>