New blist saving API
paul at darkrain42.org
Thu Jun 11 19:31:38 EDT 2009
On Jun 6, 2009, at 07:30, Sadrul Habib Chowdhury wrote:
> * Jan Kaluza had this to say on [06 Jun 2009, 13:30:09 +0200]:
>> 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.
>> 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().
Instead of relying on the UI op remove indicating the saving code
should delete the node from the storage backend, I'd prefer an
explicit "delete_node" op.
In purple_blist_add_buddy (for example), the buddy is "removed" and
then moved to a new group immediately, which should only require one
> I wouldn't tie this with the UiOps. A completely independant plugin
> could, for example, handle the loading of the blist/accounts/prefs
> Let's have something like this instead:
> gboolean (*store)(...);
> gboolean (*load)(...);
> gboolean (*save_node)(PurpleBlistNode *);
> gboolean (*save_account)(PurpleAccount *);
> gboolean (*save_int)(const char *, int);
> .. and so on and so forth for Status, SavedStatus etc. You get the
With this (and any implementation that allows UIs to overload the
saving operations), how do we support adding new information to the
structure being saved (imagine if this were implemented and we wanted
to add the current_error data to PurpleAccount)?
(I've thought about this and don't have a good solution. All I can
come up with is "require the UI to save and pass in an opaque blob
(e.g. the current XML under <account/>)", but storing that sort of
data in a database makes me die a little inside (granted: this would
still alleviate Jan's performance issues).
>> This patch also contains changes in Pidgin and Finch to work well
>> 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
I agree. If the UI doesn't provide the operations, default to the code
in (here) blistsaving.c.
More information about the Devel