[Wasabi Proposal] Live search API

Sat Jan 20 12:27:38 PST 2007

2007/1/19, Magnus Bergman <magnus.bergman at observer.net>:
>
> First some comments on the current draft[1]
> """""""""""""""""""""""""""""""""""""""""""
>
>   As with the WasabiSearchSimple API[2] the session *is* the D-BUS
>   connection. So there really doesn't need to be an explicit session
>   object. It might be adequate to have one for the language bindings,
>   but then the same thing goes for the simple API.

I actually think the session should be explicit. Both language bindings and
actual server implementations would have an easier life if it was explicit.

  If the method GetMetadata should exist I think it would make more
>   sense to make it belong to a document object, rename it GetProperty
>   and include it in the metadata storage API instead.

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.

  And as I said before, I think it makes sense to treat queries and
>   searches as different objects, which means renaming Query.Start to
>   something like NewSearch. It also means that a query doesn't need to
>   belong to anything (like the session), it could exist independently
>   (unlike a search). I have left out possible functions dealing with
>   queries (like constructing an XML query from a simple query string)
>   since functions like that rather belong in a library.

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.

  Apart from ShowConfiguration(), all functions of the simple API seems
>   to be in the live API as well.

I moved simple/live.ShowCOnfiguration to a dbus interface
org.freedesktop.search.ui.ShowConfiguration, togeteher with a new method
ShowSearchTool. Please see http://wiki.freedesktop.org/wiki/WasabiUI for the
api spec proposal. Sorry I did not find time to notify the list before now -
spare my life :-)

... So, would it be
>   possible and desirable to define the simple API as a subset of the
>   live API?

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:

Loose Idea for an Interface Merge:
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.

The simples use case, retrieving uri and dc:title, would then look something
like this (in pseudocode):

session = NewSession()
SetProperty (session, "block", "true")
SetProperty (session, "properties", "uri ; dc:title")

search = NewSearch (query_xml, session)  <-- search obj inherits requested
props from the session
hits = GetHits (search, 1000)
<show hits>

count = HitCount (search)
<print: showing 1000 of *count* hits>
Close(search)
Close(session)

The actual proposal
> """""""""""""""""""
>
> SetProperty ( in s property , in s value )
>
>     Set a global (session) property. This method can be used for
>     several things.
>       o Setting default properties for Query objects.
>       o Authentication/encryption
>       o Generally be flexible for future needs
>     * property: Name of the property.
>     * value: New value for the property.
>
> GetProperty ( in s property , out s value)
>
>     Get the value of a global (session) property.
>     * property: Name of the property.
>     * value: Current value of the property.

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).

NewSearchFromXML ( in s query_xml , out s search )
>
>     Start a new search from an XML query.
>     * query_xml: The query to execute.
>     * search: A handle that is used to uniquely identify this search.

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.

SearchClose ( in s search)

Check.

SearchSetProperty ( in s search , in s property , in s value)
>
> SearchGetProperty ( in s search , in s property , out s value)

I have a few remarks related to this above.

SearchCountHits ( in s search , out i count )

 Check

SearchGetHitProperties ( in s search, in i offset, in i limit,
>                          in as properties, out a{sa{sas}} response )

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?

signal SearchHitsAdded ( s search , i count)
>

> signal SearchHitsRemoved ( s search , ai offsets )

signal HitsHitsModified ( s search , ai offsets )

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.

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.

Cheers,
Mikkel

[1] http://www.freedesktop.org/wiki/WasabiSearchLive
> [2] http://www.freedesktop.org/wiki/WasabiSearchSimple
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070120/fb75a17a/attachment.htm 