Merging master password branch...

Elliott Sales de Andrade qulogic at
Sun May 27 00:59:32 EDT 2012

On Sat, May 26, 2012 at 7:30 PM, Richard Laager <rlaager at> wrote:
> I haven't had a chance to look at the code yet, though I keep meaning
> to. But since you brought this up again, I thought I'd ask a couple of
> design questions:

Keep in mind that I didn't design this branch and haven't had to
modify it in a while, but I'll try to answer what I can.

>> * Add `cb` and `data` parameters to `purple_account_[gs]et_password`
>> for the caller to be notified when a password is truly saved/read. I
>> don't think any callers use the saved-cb though.
> This is to make these asynchronous, correct?
> purple_account_get_password() doesn't still return a string (which would
> mean it's synchronous), does it?

Yes, purple_account_get_password is async, while
purple_connection_get_password returns NULL if nothing is cached.

> I assume libpurple keeps track of which (single) keyring backend you're
> using, and all password accesses are routed through that?

That's correct. However, once an account starts connecting and we have
the password, the PurpleConnection holds a cache of it.

> How is backwards-compatibility handled? I assume that if no backend is
> set, libpurple falls back to using the passwords in accounts.xml. Is
> that implemented of the form:
> if (backend != NULL)
> {
>    call backend
> }
> else
> {
>    hit accounts.xml
> }
> Or, is there a "legacy" keyring backend that accesses accounts.xml?

There is a legacy internal keyring backend for that.

> Does the new API use GObjects, or at a minimum, match the API/ABI of
> what it should look like if we finish the GObjectification stuff?

Unfortunately, it does not use GObjects. The internal structure
elements are not public. I'm not sure what else is needed to ensure
total GObjectification compatibility.

> The import and export functions are to facilitate moving the passwords
> from one backend to another, correct? What does import do that's
> different from the normal save() path? (I assume we'll always need some
> sort of "enumerate all passwords from this backend" export function.)

I haven't looked into it with much detail, but it appears these
functions actually facilitate saving any additional information in
accounts.xml that may be required to retrieve the password from a
backend. I'm not sure if that's only helpful for the internal backend,

> --
> Richard

Elliott aka QuLogic
Pidgin developer

More information about the Devel mailing list