Simple search API proposal, take 2

[Jamie McCracken]

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.

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...


> 
>     - 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 :)

-- 
Mr Jamie McCracken
http://jamiemcc.livejournal.com/