New blist saving API

[Sadrul Habib Chowdhury]

* Jan Kaluza had this to say on [06 Jun 2009, 13:30:09 +0200]:
> 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.

Cool!

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

I wouldn't tie this with the UiOps. A completely independant plugin
could, for example, handle the loading of the blist/accounts/prefs etc.

Let's have something like this instead:

store.c:
PurpleStore
{
	gboolean (*store)(...);
	gboolean (*load)(...);
};

store/blist.c:
PurpleStoreBlist
{
	PurpleStore;
	gboolean (*save_node)(PurpleBlistNode *);
};

store/account.c:
PurpleStoreAccount
{
	PurpleStore;
	gboolean (*save_account)(PurpleAccount *);
};

store/prefs.c:
PurpleStorePrefs
{
	PurpleStore;
	gboolean (*save_int)(const char *, int);
	...
};

.. and so on and so forth for Status, SavedStatus etc. You get the idea.

I believe InstantBird uses something other than the standard .xml files
libpurple uses for some of the stuff. Folrian, do you have any
suggestions in this regard?

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

Ideally, I think, it would be better if the change is completely
transparent to the client. So there will be no change *necessary* in
Pidgin or Finch, although some change for enhanced performance should be
OK.

Sadrul