[Authentication] Small API issues

[Stef Walter]

Michael Leupold wrote:
> These are some small API issues that I'd like to see corrected:
> (@Stef: do you rather want text or diffs?)
> 
> 1. Signals:
> - org.freedesktop.Secrets.Collection.CreatedItem => ItemCreated
> - org.freedesktop.Secrets.Collection.DeletedItem => ItemDeleted
> seems to be a more common way to name a signals (thanks to Kevin Krammer for 
> coming up with those)
> - org.freedesktop.Secrets.Item.changed => ItemChanged
> just "changed" seems to be ambiguous.

Good. Will do.

> 2. Methods:
> - org.freedesktop.Secrets.Session.CompleteAuthenticate - second argument 
> should be OUT

Roger.

> - org.freedesktop.Secrets.Session.Negotiate should get an argument OUT bool 
> successful

Yes, or a tristate: continue = -1, success = 1, failure = 0

> - how about org.freedesktop.Secrets.Session.SupportedAlgorithms(OUT 
> Array<String> algorithms) to faciliate negotiation?

Makes sense. Although I was kind of hoping to do without this.

> 3. Object paths:
> - Object paths could be shorter. I'd advocate /<apiname> (eg. /Secrets/...) 
> effectively stripping the /org/freedesktop prefix.

Are you sure that's the right way to do things? Object paths are global
to the dbus bus, and should have a unique prefix.

> - I'd add that item identifiers on the object path MUST be unique identifiers 
> that MUST be persistent. That way we could guarantee that synchronization will 
> work.

Interesting, good idea. I think we should put this in the API.

> - For the very same purpose I'd also add a unique identifier (UUID) property 
> to Collection as renaming them is possible and they thus can't be identified 
> using their label. I'd prefer if collections had this uuid as their object 
> path as well.

The object path doesn't need to have anything to do with the label. You
could use a UUID in the object path if an implementor so desires. I
think we should leave the object path as the unique identifier.

> 4. Errors:
> - add org.freedesktop.Secrets.Error.NoSession for methods calls which require 
> a session but have none

Very likely a good idea, but let's add errors as we need them. Which
methods would return this? If you list them I'll it to the documentation.

Cheers,

Stef