[XESAM] API simplification?

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Wed Jul 18 07:22:39 PDT 2007


2007/7/18, Fabrice Colin <fabrice.colin at gmail.com>:
>
> On 7/16/07, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> > I have a few suggestions for updates to the xesam search spec.
> >
> > * API:
> > Remove the session properties search.blocking and search.live. These
> seemed
> > to cause more confusion than I anticipated. These can be emulated in the
> > client side lib as far as my scribblings can tell. Anoter solution might
> > just be better documentation of course...
> >
> +1 from me.
>
> > What this would mean for the api methods:
> >  * GetHits should always block until the requested number of hits has
> been
> > found or the entire index has been searched (in which case the
> SearchDone
> > signal will be emitted too).
> >  * CountHits should always block until the entire index has been
> searched
> >  * No other methods should block
> >
> Okay.


Good, I shall try and punk people on IRC to get more opinions on this.

> * Query Language:
> > I suggest we remove the "type" attributeon the query element. You can
> just
> > specify the Category- or StoredAs fields in you selectors.
> >
> What are these ? I can't find either in the xsd file.


They are fields in the upcoming ontology :-) Sorry for the obscure
reference. So the idea is to replace

<query type="Foo">
MY-QUERY-XML
</query>

with

<query>
  <equals>
    <field name="xesam:category"/>
    <string>Foo</string>
  </equals>
</query>

it is more verbose but is also more coherent with the rest of the spec.

What do you think about the idea that the server was free to forget hits as
soon as they are read if search.live == false? Which as said before would
imply that GetHitData should probably return an empty list if search.live ==
false.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070718/5da3e9e0/attachment.html 


More information about the xdg mailing list