Re: Proposing Tracker for inclusion into GNOME 2.18



James Henstridge wrote:
On 25/10/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
James Henstridge wrote:
> While having standard names for metadata relationship types that
> everyone can use is great, there are going to be cases where apps want
> to experiment with relationships that haven't yet been standardised.
>
> Would an app be able to do this without modifying tracker?  Is there
> any guidelines about how a project should namespace such metadata to
> make sure it doesn't conflict with what other applications are doing?

the guidlines state that it should be namespaced with the application
name EG "Nautilus.WindowSize" would be an app specific metadata whilst
something like "User.Foo" would be a user defined one

>
> The RDF solution to the namespace problem is to use URIs for the
> property names, which have well understood namespacing to start with.
> Would you suggest apps using tracker do likewise?

possibly although its a bit cumbersome - we could use the dbus way of
Org.Gnome.Nautilus.WindowSize but im not sure if we need to? Would
application names overlap?

The thing in common between RDF style property naming and dbus
interface naming is the inclusion of a DNS name in the identifier.
This delegates the job of making sure identifiers are unique to the
DNS system.  It is then the job of the domain owner to make sure the
identifiers underneath don't conflict.

So the question is whether this level of assurance is needed.  It is a
bit hard to tell at this point, but there certainly have been cases of
application name conflicts in the past.

okay it might be best to play safe here and use the dbus style



>> A contact can only have one metadata value per type (this is a primary
>> key constraint)
>
> For a lot of types of metadata you often have multiple values
> associated a single metadata type.  For example, I have multiple email
> addresses.  Having separate "work email" and "home email" metadata
> types might solve the problem in a lot of cases, but what if someone
> has multiple work emails?

if we use the vCard spec for our contacts then it would depend on
whether vCard supports that?

>
>
>> With everything mapped 1:1 you can then use RDF query to search them
>
> Why would you need a 1:1 mapping to do a query?  A query for "contacts
> with an email of jamiecc blueyonder co uk" should be possible
> independent of the number of email addresses a contact can have.

we need the 1:1 mapping to get/set the values. Whatever we implement we
must have a unique metadata name for a particular service in order to do
that otherwise getting or setting a value would be impossible.

One problem with metadata relationships is that some metadata like in
the above case would only be searchable like Contact.JabberID as the
actual storage would be in Contact.WorkJabberID or Contact.HomeJabberID
so it might get confusing for developers if they try and get the value
of Contact.JabberID which would be NULL.

It would be very useful to be able to ask for all the Jabber IDs or
email addresses of the contact (returning 0 or more results).

yes this is why we will have dedicated dbus interface for each first class object so that we can provide convenience methods that help remove the complexity and improve performance over using the more generic low level API's.


--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]