Simple search API proposal, take 2

[Mikkel Kamstrup Erlandsen]

2007/1/15, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
>
> Mikkel Kamstrup Erlandsen wrote:
>
> > The return value could be stripped of all maps and use the same ordering
> > of properties as in the properties input value. Fx the call:
> >
> >   GetHitProperties (query_handle,0, 2, ["uri", "dc:title", "mime"])
> >
> > could return:
> >
> > [
> >  ["file:///home/mikkel/delta_comp.pdf
> > <file:///home/mikkel/delta_comp.pdf>", "Delta Complexes",
> "application/pdf"]
> >  ["file:///home/mikkel/summa.svg", "Summa Logo", "image/svg+xml"]
> > ]
> >
> >  From an optimization point of view this is probably the best we can
> > get. This is also how track er currently does, and it is relatively easy
> > to work with.
> >
> > The reason why I'm hesitating to go for this solution is the live api.
> > It would be really nice to be able to use the same data structures here.
> > The live api however has a need to be able to tell the consumer that
> > *this particular hit* has become invalid.
> >
> > A way around this could be to always have the first element in the
> > response list be a unique hit identifier. Or the last element for that
> > matter - this way the returned properties would have the same indices as
> > the requested properties.
>
> or just make sure the result set always includes the HitID as the first
> element and the rest follows the same order as the properties list. The
> HitID can then be used in live queries to signal changes.
>
> (in tracker, the uri is always the first element and the rest follow the
> order of the properties though I could easily change this to a HitID)
>
> >
> > We could ease up on the global-identifier thing, and just let the
> > identifier be relative to the given query handle.
> >
> >     - Using URI as key: as previously stated I think that this is a bad
> >     idea.
> >
> >
> > +1
>
> I am not bothered whether we use the uri or a HitID to uniquely identify
> the hit - I suspect most clients (Nautilus, Deskbar, T-S-T,
> beagle-search) will probably use the uri even with the (negligible) race
> conditions.


The HitID would be opaque, so any server could use the uri if it wanted to
do that.


If a HItID is used it could place extra burden on the client to manage
> HitID->URI transfers. I guess looking at real world apps and their needs
> will determine which is more suitable...



I don't think I understand the complications... What is the problem in
requesting the uri property of the hits?


>     - Accessing Snippets individually: no need for GetSnippets(), use:
> >       GetHitProperties(query_handle, offset, 1, ["Snippet"])
> >
> >
> > As far as I can tell, this is the general consensus...
>
> yes thats fine - just need a list of all the common properties :)


I fear that this has to wait for the metadata spec... Maybe we could agree
on a small set of absolutely needed properties (like, uri, snippet and mime)
.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070115/432028e4/attachment.htm