2007/1/19, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">magnus.bergman@observer.net</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
First some comments on the current draft[1]<br>"""""""""""""""""""""""""""""""""""""""""""
<br><br> As with the WasabiSearchSimple API[2] the session *is* the D-BUS<br> connection. So there really doesn't need to be an explicit session<br> object. It might be adequate to have one for the language bindings,
<br> but then the same thing goes for the simple API.</blockquote><div><br>I actually think the session should be explicit. Both language bindings and actual server implementations would have an easier life if it was explicit.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If the method GetMetadata should exist I think it would make more<br> sense to make it belong to a document object, rename it GetProperty
<br> and include it in the metadata storage API instead.</blockquote><div><br>Yes, it looks out of place in the search interface. There does however need to be a way to obtain the "expensive" hit metadata as discussed in the thread about the simple api.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> And as I said before, I think it makes sense to treat queries and<br> searches as different objects, which means renaming
Query.Start to<br> something like NewSearch. It also means that a query doesn't need to
<br> belong to anything (like the session), it could exist independently<br> (unlike a search). I have left out possible functions dealing with<br> queries (like constructing an XML query from a simple query string)<br>
since functions like that rather belong in a library.</blockquote><div><br>I follow you on the search/query separation. Having NewSearch() actually start the search gives some problems with the SearchSetProperty() since it doesn't make much sense to change properties on a running search. Spotlight has some similar methods and they restart the search if you invoke them. The reason I included a
Query.Start - in current context Search.Start, was exactly that it should be possible to set properties on a Search/Query before it was actually run.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Apart from ShowConfiguration(), all functions of the simple API seems<br> to be in the live API as well. </blockquote><div><br>I moved simple/live.ShowCOnfiguration to a dbus interface org.freedesktop.search.ui.ShowConfiguration
, togeteher with a new method ShowSearchTool. Please see <a href="http://wiki.freedesktop.org/wiki/WasabiUI">http://wiki.freedesktop.org/wiki/WasabiUI</a> for the api spec proposal. Sorry I did not find time to notify the list before now - spare my life :-)
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">... So, would it be<br> possible and desirable to define the simple API as a subset of the
<br> live API?
</blockquote><div><br>I have ambivalent feelings on this issue. Let me outline pros and cons as I see them. I shall spare you my confusing thoughts and cut to the cheese:<br></div><br>Loose Idea for an Interface Merge:<br>
Have a boolean session property called "block". If it is true, GetHits() and CountHits() blocks until the desired info is available, removing the need for signals. If there are less hits than requested in by GetHits when the entire index have been searched, just return the found items.
<br><br>The simples use case, retrieving uri and dc:title, would then look something like this (in pseudocode):<br><br>session = NewSession()<br>SetProperty (session, "block", "true")<br>SetProperty (session, "properties", "uri ; dc:title")
<br><br>search = NewSearch (query_xml, session) <-- search obj inherits requested props from the session<br>hits = GetHits (search, 1000)<br><show hits><br><br>count = HitCount (search)<br><print: showing 1000 of *count* hits>
<br>Close(search)<br>Close(session)<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The actual proposal<br>"""""""""""""""""""
<br><br>SetProperty ( in s property , in s value )<br><br> Set a global (session) property. This method can be used for
<br> several things.<br> o Setting default properties for Query objects.<br> o Authentication/encryption<br> o Generally be flexible for future needs<br> * property: Name of the property.<br> * value: New value for the property.
<br><br>GetProperty ( in s property , out s value)<br><br> Get the value of a global (session) property.<br> * property: Name of the property.<br> * value: Current value of the property.</blockquote><div><br>As noted above I still think we need a session handle. By using handles we could even Get/SetProperty to take both a session- or a search handle. Like SetProperty(handle, prop, val).
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">NewSearchFromXML ( in s query_xml , out s search )
<br><br> Start a new search from an XML query.<br> * query_xml: The query to execute.<br> * search: A handle that is used to uniquely identify this search.</blockquote><div><br>If the searches/queries can have properties I think we need a intermediate StartSearch() method. I can accept that if we decide to only have session properties then to start the search right away.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SearchClose ( in s search)</blockquote><div><br>Check. <br></div><br><div> </div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SearchSetProperty ( in s search , in s property , in s value)<br><br>SearchGetProperty ( in s search , in s property , out s value)
</blockquote><div> <br>I have a few remarks related to this above.<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SearchCountHits ( in s search , out i count )
</blockquote><div><br> Check</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SearchGetHitProperties ( in s search, in i offset, in i limit,
<br> in as properties, out a{sa{sas}} response )</blockquote><div><br>I think it should be called GetHits. Why list requested props here if you also do it in the Set*Property()? Why do we need an offset? In a live search I can't see any reason to re-request a given range of hits. Didn't we agree that the return value should be without maps and just arrays?
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">signal SearchHitsAdded ( s search , i count)<br></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
signal SearchHitsRemoved ( s search , ai offsets )</blockquote><div> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">signal HitsHitsModified ( s search , ai offsets )
</blockquote><div><br>Is this why you want to be able to refetch pages in GetHitProperties? If I recall correct this signal is why I included the GetMetadata method in the first place.<br></div><br><br>How do you cater for snippets? If you again want to use the GetHitProperties method I can see the solution, but I must say that it appears inelegant to use GetHitPropeties like this - for results, updates, and snippets.
<br><br>Cheers,<br>Mikkel<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[1] <a href="http://www.freedesktop.org/wiki/WasabiSearchLive" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.freedesktop.org/wiki/WasabiSearchLive</a><br>[2] <a href="http://www.freedesktop.org/wiki/WasabiSearchSimple" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.freedesktop.org/wiki/WasabiSearchSimple
</a><br></blockquote></div><br>