2007/1/15, Jamie McCracken <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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: > > [ >  ["<a href="file:///home/mikkel/delta_comp.pdf">file:///home/mikkel/delta_comp.pdf</a> > <<a href="file:///home/mikkel/delta_comp.pdf">file:///home/mikkel/delta_comp.pdf </a>>", "Delta Complexes", "application/pdf"] >  ["<a href="file:///home/mikkel/summa.svg">file:///home/mikkel/summa.svg</a>", "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.</blockquote><div> The HitID would be opaque, so any server could use the uri if it wanted to do that.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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...</blockquote><div> I don't think I understand the complications... What is the problem in requesting the uri property of the hits? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">>     - 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 :) </blockquote><div> 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) . </div>Cheers, Mikkel </div>