On 31/12/06, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> wrote:
2006/12/24, Jean-Francois Dockes <[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. 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. 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. Not having it would mean either not having the above functionality in the app, it being implemented on top (probably duplicating stuff implemented in some backends), or not using the API and just talking to backends that support it directly. Cheers, James "Doc" Livingston
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
