[Authentication] Item attributes types inconsistency

[Stef Walter]

On 03/14/2011 11:27 PM, Valentin Rusu wrote:
> On 03/14/2011 09:56 PM, Stef Walter wrote:
>> On 03/13/2011 10:47 PM, Valentin Rusu wrote:
>>> First, when creating an item, the signature of the CreateItem has a
>>> "properties" arg of type "a{sv}".
>> Yes, these are the various readwrite properties (as in o.f.d.Properties)
>> of the item. Usually one is the Label and the other is the Attributes.
> Ok, I gave the spec a second reading and got the distinction between
> d-bus related properties and item's properties, which are called
> attributes.

Right, but the item's attributes are not properties. An item has the
following properties defined by the specification. In the future more
may be defined, or others may be present on an implementation.

 * Label (string)
 * Created (uint64)
 * Modified (uint64)
 * Locked (boolean)
 * Attributes (dict<string, string>)

The various properties above contain metadata about the item. Only some
of those properties are writable: the Label and Attributes properties.

Attributes are a map used by implementations to lookup an item. Many
databases only have one lookup key, but we have more than one lookup
key. This allows flexibility for storing and then later retrieving items
that match a given use case or application.

Perhaps the name 'attributes' makes this less clear. Maybe we should
have used 'keys' or 'index' or something along that line. But now it's
too late to change that name.

For example google chrome stores items with attributes that look like
the following example, but each application can store a different set of
attributes.

username_value: gcohenro
action_url: http://ec.europa.eu/avservices/download/video_download_en.cfm
signon_realm: http://ec.europa.eu/
password_element: UserPassword
username_element: UserLogin
origin_url: http://ec.europa.eu/avservices/download/video_download_en.cfm
application: chrome

When applications want to share items, they have to agree on a
consistent set of attributes to use.

> However, giving them all in a single nested map is
> misleading. Why not simply have two parameters :
> - properties "a{ss}"
> - attributes "a{ss}"

Because the item's properties can have many different types, hence the
a{sv}. The 'Attributes' map is just one of the properties on an item.

> That way this would ensure users correctly understand that item's
> attributes are only strings (I also like this more simpler type).

Yes, that's good. All the attributes only consist of strings as
designed. That's why the type of the Attributes property is a{ss}.

Some of these fundamental things have already been defined on this
mailing list with lots of input from various desktops and implementations.

I'm not saying that changes aren't welcome, but I think that at this
stage we need to limit ourselves to fixes for things that are broken.
The fixes we put in recently represented things that made the API
unusable or broken in certain ways. Hopefully we've found all those now,
and we can move forward with finalizing what we have.

Cheers,

Stef