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

[Mikkel Kamstrup Erlandsen]

2006/12/31, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
> James "Doc" Livingston wrote:
>
> > 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

An Object.Moved signal does not seem right in a search api, it seems
more like a metadata service thing...

Currently the live interface proposed in
http://wiki.freedesktop.org/wiki/WasabiSearchLive has the three
signals Query.{HitsAdded, HitsRemoved, HitsModified}. The argument
passed along the HitsModified signal is a a{sa{sas}} (a map of
uri->{prop1->[vals], prop2->[vals],...}). Since the map keys are uris
it is not possible to fire a HitsModified if a file is moved.

If we don't want to take the HitsRemoved(file) HitsAdded(file) road
when moving files, we'd have to rely on another key for the file.

I am beginning to see the need for a unique identifier that is not
defined from location on the filesystem or any other thing. A totally
abstract identifier. Fx. an integer or string. This identifier will
not change if the object is moved or renamed. Uri would then be
demoted to a property of the hit.

Then the current suggested api will work for object-moves, without
doing the remove/add dance.

With an abstract identifier an app wouldn't even need to store uris. A
music player for instance could just request the uri property for an
item when it is about to be played. Then it would even need to care
about file moves.

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

Like I describe above the app could request the uri property of the
object only right before activation (fx. playing of music file), then
the race condition would be reduced to a theoretic one I think (you
have to delete the file in the time space from the service return the
uri and the app starts actual playback).


The question as I see it is really "is opaque identifiers a good idea?".

Cheers,
Mikkel