simple search api (was Re: mimetype standardisation by testsets)
jamiemcc at blueyonder.co.uk
Sun Dec 31 14:53:19 EET 2006
James "Doc" Livingston wrote:
> On 31/12/06, *Mikkel Kamstrup Erlandsen* <mikkel.kamstrup at gmail.com
> <mailto:mikkel.kamstrup at gmail.com>> wrote:
> 2006/12/24, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr
> <mailto:jean-francois.dockes at wanadoo.fr>>:
> Oops, yes, you're right the URI can change too.
> Whether an uri can "change" or not is merely a matter of definition.
> I agree, but it is fairly important which way around the definition is.
> Not because it's a URI<->Object is a bad idea, just that we need to be
> aware that we're making that decision.
> URIs not being able to change and being a 1:1 mapping makes some things
> easier, like not having to retrieve the URI for all the hits. On the
> other hand, it means that any application that wants/needs persistent
> identifiers for things that can move must implement it themselves.
the moved signal would specify moved_from_uri and moved_to_uri so it
should not be an issue for client apps. They can safely use the uri as
the identifier for a file and adjust whenever they get that signal
> If an object changes uri it might as well be regarded as another
> object all together. The end user will see it as a rename/move but
> in the api I think we should go for the delete-create metafor.
> Meaning that the is a one-to-one correspondence between objects and
> One place where the API could be used, and is the area I'm most familiar
> with, is a music playing application. The search API would be useful to
> be able to say "give me all the user's music", rather than the
> "importing" step that you need to do in many music apps.
> Many music apps also hold extra metadata about the user's music (play
> counts, etc), and having the extra metadata lost when the user moves
> some files around is annoying. If the URI of something could change (and
> the backend implementation supported it), we could keep track of the
> metadata across file renames or moves.
In tracker, we store everything for a file/entity against a unique
ServiceID so all metadata is independent of uri and moves with a file
automatically but not sure if exposing this ID field in the Dbus
interfaces is a good idea? (most apps are only interested in uris)
> Being able to do thing like that may not be worth the extra complication
> of URIs and objects not being one-to-one - as long as we realise we've
> decided that.
the only problem really is a possible race condition where a uri has
changed while calling a method with the old uri - in practice this is
unlikely to happen very often though (and the race would still exist if
a file was ever deleted).
Mr Jamie McCracken
More information about the xdg