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

[Mikkel Kamstrup Erlandsen]

2006/12/31, James Doc Livingston <doclivingston at gmail.com>:
>
> On 31/12/06, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> >
> > 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.



Yeah this is a problem. I don't think it can be fixed in a good way without
a real metadata server (like tracker). Unless you have a service always
monitoring the files, metadata will get lost on file moves as you say.

Apps can work around this file-moving problem without a metadata server in
various ways. - Fx. storing a database of uri<->md5sum, and diff it against
the music files found on each startup. Then calculate md5sums of new files
and pickup metadata according to md5sums. Anyway this is not really relevant
for the discussion.

An interface spec for a metadata server is next on the list after we finish
the search interface.


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.



Unless somebody come up with a real good reason I think we should settle on
the uri<->object relationship.



Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070101/71c2504f/attachment.htm