James "Doc" Livingston wrote:
On 31/12/06, *Mikkel Kamstrup Erlandsen* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
2006/12/24, Jean-Francois Dockes <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
