Merging master password branch...

[Elliott Sales de Andrade]

On Sat, May 26, 2012 at 7:30 PM, Richard Laager <rlaager at wiktel.com> 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,
though.

> --
> Richard

-- 
Elliott aka QuLogic
Pidgin developer