Simple search API proposal, take 2

[Mikkel Kamstrup Erlandsen]

2007/1/18, Jean-Francois Dockes <jean-francois.dockes at wanadoo.fr>:
>
> 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"
>
> Or did I not understand you ?


I'm pretty sure that we actually agree everybody :-)

The return value is an array of arrays of properties. There are not maps
involved anywhere. Fx: a search with a single hit and one prop: [[value]]. A
search with two hits and three properties: [[value1, value2, value3],
[value1, value2, value3]] - here valueN is the value of the N'th property in
the GetHits request.

The tricky part is what a "property" is then. Since we should allow
multivalued properties (think "email:cc") we have two choices:

1) The type of a property is a dbus Variant. Meaning a container type with a
value and a type. This would allow accessing fx file:size an integer and
email:cc as an array of strings. The dbus signature of the return type is
then "aav".

2) A property is an array of strings representing the value(s). This gives a
dbus signature for the return type "aaas".

I'm inclined towards 2), but I know that not everybody agrees with me :-)
Please speak up.

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