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

[Tomasz Wasilczyk]

2013/4/9 Mark Doliner <mark at kingant.net>:
> 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.

I think that relying on points collecting can mislead users. For me,
importance of a change could be divided as follows:
- not_important - such changes doesn't trigger saving to disk,
sheduled save will be done once per 30 minutes or 15 minutes if disk
is awoken (I don't know, if it is possible to check)
- important - will be saved within 5 seconds
- extremely_important - will be saved at once (I'm not sure, if this
is necessary)

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

I would suggest working with 3.0.0 - it's an API heaven.

Tomek