[XESAM] Spec update proposals

[Jos van den Oever]

2007/6/22, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> Really cool that you stepped up an did this. Thanks a bunch :-)
>
> A few questions regarding your test:
>  - Do you pass the string as argument and return it again, or do  you
> just pass it as argument and return void?
I called CountHits() so input was a string and the return value was an
int (that i did not calculate).
>  - Just to be 100% clear. Are we talking UTF-8 strings of N characters
> or N bytes?
all ascii, so both

In addition, the overhead for 0 calls was 0.07 seconds, so that's negligible.

> Regarding the search spec - I'm not outright against using the query's
> string representation for the key, but it does have a few consequences
> we should bear in mind.
>
> It is for example likely that apps use some kind of toolkit to build
> queries in an object oriented manner - never seeing the string
> representation.
>
> If this query construction API is integrated with the actual client
> side xesam bindings so that you do fx:
>
>     search = client.newSearch (new UserQuery("hello world"))
>
> there is no problem. But the point is that it forces me to couple the
> query-construction toolkit with the client side xesam search toolkit.
> While this is probably the easiest way anyway, it is still a price we
> accept.
>
> Historical Note:
> Using the query string as search handle was in fact one of the first
> proposals for the xesam search spec. I think we better dig out why it
> was rejected then...

Would we want NewSearch() to give a return value? After all the return
value was the reason for the race condition. Returning a bool would be
ok though, I guess. Even though it might arrive later than the first
HitsAdded() signal. I do not know how a lib like python would deal
with that actually. I would hope it would still report it. Until the
function returns false, the client should assume the call succeeded.

Something I did not take into account is how the server deals with
equal queries. If they are in different sessions, they would have
different preferences and hence different hits. So the map<query,
searchobject> would not suffice; one would need to add the session
name or the client bus to the key too.

A longer key would be a bit more expensive to retrieve the object
with. I did not the effect of this. It is probably negligible.

I would prefer to see client code like this:

query = new XmlQuery("hello world")
if (!client.NewSearch()):
    handleError()
    return
count = client.CountHits(query)

Cheers,
Jos