2006/12/31, Jamie McCracken <[EMAIL PROTECTED]>:
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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
