Simple search API proposal, take 2

[Magnus Bergman]

On Thu, 18 Jan 2007 17:54:03 +0100
Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr> wrote:

> Magnus Bergman writes:
>  > On Fri, 12 Jan 2007 08:41:10 +0100
>  > Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr> wrote:
>  > >   I think that the sequence number can be kept implicit:
>  > > 
>  > >     Query (in s query_string, out i query_handle)
>  > >     GetHitProperties ( in s query_handle, in i offset, in i
>  > > limit, in as properties, out (sequence of maps)
>  > > response )
>  > 
>  > What you call "offset" is exactly what I meant by "sequence
>  > number", if I didn't misunderstand something. The alternative
>  > (really keeping it implicit) would be to completely leave it out
>  > and just return the bunch of hits (much like how read(2) works.
>  > But that would also require a function similar to lseek(2), so I
>  > guess it wouldn't be simpler anyway.
> 
> What I mean by:
> 
> GetHitProperties ( in s query_handle, in i offset, in i limit, 
>                    in as properties, out (sequence of maps) response);
> 
> is: return "limit" hits starting from offset "offset". This is a
> combined lseek/read call. 
> 
> I propose that the hit numbers should be implicit *in the response*.
> We know that it contains an ordered list of hits from number "offset"
> to "offset+limit-1", so I think that there is no point in repeating
> the hit number for every entry, as would (in your words): "A map
> mapping each hit (sequence number) to a map of property-list of
> values pairs" 

I was referring to how it would be handled by the search engine
(instead of having an opaque identifier for each hit). To include the
sequence/index numbers in the result didn't cross my mind. In other
words, we seem to agree completely on this.