New blist saving API

[Jan Kaluza]

On Sat, Jun 6, 2009 at 4:30 PM, Sadrul Habib Chowdhury<imadil at gmail.com> wrote:
> * 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.

This could be also solution (probably better one). In this case, user
is be able to change backend, which is cool feature. This will be also
transparent to UI in the case that plugins can be loaded by default by
libpurple. Can they do it?

I suppose the read/write code should be then removed from blist.c, so
I can add some signals to the purple_blist_load and
purple_schedule_save functions, which can be handled by plugin, so
there will be also backward compatibility with UIs.

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

Thanks for your response

Jan "HanzZ" Kaluza