2007/1/18, Jean-Francois Dockes <<a href="mailto:jean-francois.dockes@wanadoo.fr">jean-francois.dockes@wanadoo.fr</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Magnus Bergman writes: > On Fri, 12 Jan 2007 08:41:10 +0100 > Jean-Francois Dockes <<a href="mailto:jean-francois.dockes@wanadoo.fr">jean-francois.dockes@wanadoo.fr</a>> 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 ?</blockquote><div> 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 </div> </div>