On 31/12/06, Jamie McCracken <[EMAIL PROTECTED]> wrote:
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
That still has problems if the file gets moved or renamed while the
app in question isn't running.
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)
Perhaps I'm thinking about this the wrong way around. Maybe having a
"persistent id" property which backends could provide (if they support
it) would work better, as it would let apps the don't care just use
URIs, while still letting apps that do care have a backend-neutral way
of getting one.
It would pretty much solve the use-cases I can think of, and not
affect the "normal" use cases.
Cheers,
James "Doc" Livingston
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
