[Authentication] Small API issues

[Michael Leupold]

On Wednesday 15 July 2009 19:06:51 Stef Walter wrote:
> Michael Leupold wrote:
> > - org.freedesktop.Secrets.Session.Negotiate should get an argument OUT
> > bool successful
>
> Yes, or a tristate: continue = -1, success = 1, failure = 0

I'm not sure what "continue" is there for but if you think this is useful with 
certain negotiation protocols I'm ok with it.

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

Well, maybe specifying a required fallback might help to get rid of it. I'm 
not sure if this will actually work well if you have plenty of algorithm 
combinations.

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

As I understand it object paths are local to the service name. From what I see 
in other protocols some seem to use /org/freedesktop while others use 
/Servicename.

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

Yeah, I messed that up. I'd do the same like for Items (state that the object 
path is unique and must not change as collections are refered to by 
applications).

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

I'd put that on Service.SearchItems and Service.RetrieveSecrets as the service 
interface will be available even if no session exists.

Regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/authentication/attachments/20090715/1e762872/attachment.pgp