Merging master password branch...

[Richard Laager]

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:

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

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

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?

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?

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

-- 
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20120526/b3e5f2e2/attachment.sig>