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

[James "Doc" Livingston]

On 31/12/06, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
>
> 2006/12/24, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr>:
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061231/6989b80b/attachment.htm