simple search api (was Re: mimetype standardisation by testsets)

[Jamie McCracken]

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
>     uris.
> 
> 
> 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
http://jamiemcc.livejournal.com/