New blist saving API

[Jan Kaluza]

Hi,
some days ago, I've written patch (attached to this email) which
allows applications, which use libpurple, to choose how they want to
save/load blist data (currently stored in blist.xml). The goal is to
make it easy to write for example mysql backend for blist storing
without any change in libpurple code. In this email, I want to ask
you, if that's good idea and if you have any question about my
implementation.

About the patch:

This patch moves all blist.xml read/write functions from blist.c to
special file blistsaving.c for backward compatibility and it also
moves purple_blist_load() and purple_blist_schedule_save() from
blist.h/blist.c to blistsaving.h/blistsaving.c. It adds new
PurpleBlistUiOps function called save_node(PurpleBuddyList *blist,
PurpleBlistNode *node) which is called every time the node is changed
(it replaces all purple_schedule_save() in blist.c) and it's up to UI
to save it how it wants. For backward compatibility, there is
purple_blist_save_callback(PurpleBuddyList *blist, PurpleBlistNode
*node) defined in blistsaving.h, which can be used for save_node op
and simply calls purple_schedule_save().

This patch also contains changes in Pidgin and Finch to work well with
my new API.

It's one of my first patches for libpurple, so feel free to tell me
what I'm doing wrong and what could be done better.

Thanks for response
Jan "HanzZ" Kaluza
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abstract_blist_save.diff
Type: text/x-diff
Size: 51049 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20090606/7833a0e6/attachment-0002.diff>