New blist saving API

[Florian Quèze]

On Sat, Jun 6, 2009 at 16:30, Sadrul Habib Chowdhury<imadil at gmail.com> wrote:

> I believe InstantBird uses something other than the standard .xml files
> libpurple uses for some of the stuff.

That's right. Instantbird stores the buddy list in an sqlite database.
The preferences are stored in the standard Mozilla preference system,
and the accounts are stored in the preference system too, like
Thunderbird does for email accounts.

>Folrian, do you have any suggestions in this regard?
>

The first thing I should say is that it's not required to make any
change to libpurple to be able to store the buddy list in something
else than the xml file. Using the signals and blist uiops gives enough
information to the UI to know what it should store.
I used to have a very ugly workaround to prevent libpurple from
writing the blist.xml file to disk. Now that Instantbird uses a
modified libpurple anyway, I have just ifdef'ed out that part of the
code.

That being said, something like the new API you propose would be a
great improvement, at least for the buddy list.

I'm not sure it is really needed for accounts. I think most operations
on accounts that need to be saved come from the UI, so the UI already
knows when an account needs to be saved. And it's obvious that the
account list needs to be loaded when the UI starts.

For the preferences, this is likely not the API UI developers would
want. The only reason I see for not wanting to use the standard
prefs.xml file is that the application framework used for the UI
already provides a preference system that should be used.
In this case, the API should provide a way to replace the preference
system, not to replace the way the preference system stores its file.

I would prefer something like:
struct _PurplePrefsUiOps
{
	void (*add_none)(const char *name);
	void (*add_bool)(const char *name, gboolean value);
	void (*add_int)(const char *name, int value);
	void (*add_string)(const char *name, const char *value);

	void (*set_bool)(const char *name, gboolean value);
        ...
}

It is totally possible to do this without changing existing APIs. It
would only require adding:
void purple_prefs_set_ui_ops(PurplePrefsUiOps *ops);
and maybe:
PurplePrefsUiOps *purple_prefs_get_ui_ops(void);

It would then be possible to move the current libpurple preference
system implementation to other source and header files that UIs could
choose to not compile.

The prefs.c file could contain something like:

#ifdef PURPLE_NO_DEFAULT_PREF
static PurplePrefsUiOps *prefs_ui_ops = NULL;
#else
#include "prefs-impl.h"
static PurplePrefsUiOps *prefs_ui_ops = default_prefs_ops;
#endif


I think a similar solution would be interesting too for the DNS API
(which already uses PurpleDnsQueryUiOps). It would make it easy to
separate the Windows and Unix implementations in different files,
which would make these files much more readable. And for UIs that
don't use the libpurple dnsquery implementation, it would make it easy
to not compile the default implementation.

If this seems right to you, I would be happy to help and write the
patch for the refactoring of the preferences system and maybe the DNS
API too.

-- 
Florian Quèze