2007/3/2, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2007/2/28, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>: > Calling all desktop search gurus of the known web, > > > We are nearing deadline for the search spec (see > <a href="http://wiki.freedesktop.org/wiki/WasabiRoadMap">http://wiki.freedesktop.org/wiki/WasabiRoadMap</a>), > and I have collected a few highlights of my discussions at FOSDEM. > >  - Generally there where interest in better introspection capabilities to > have dynamic UIs that adapt to the features of the search engine. > >  - The ShowSearchTool method in the UI interface was greatly criticized. > Should we - or should we not, have it? As a deskbar dev I would like it, > since not everybody likes live results, but if deskbar would be the only > consumer then I think I could accept life without it :-) > >  - We need some command line tools to test and help developing the backends. > I (Mikkel Kamstrup) volunteered to do some in python/glib. > >  - There was desire to add a way to introspect all indexed field names (not > all indexers might support the entire metadata spec when it is ready) > >  - In the end user search spec > (<a href="http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage">http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage</a>) > it should be clarified that you can use words or phrases (with modifiers) as > values in Selectors. As the spec stands now it is actually there if you read > carefully, but it can be visualized via the structure drawing as well (see > the wiki page for new+old version). > >  - How should we cater for remote search services or searches on remote > machines (it is not necessarily the same)? > > > Proposed "diff" to the current API: > ---------------------------------------------- > >  - Add a session parameter to the GetQueryExtensions method, so that the > signature becomes GetQueryExtensions (in s session, out as extensions) since > there might be some future query extensions where their availability > actually depends on the session state. > >  - Add a session property that holds the supported Wasabi spec version of > the backend > >  - Rename the session properties sort.property.{primary ,secondary} to > sort.{primary,secondary}. > >  - Method to inspect the state of the indexer, something like GetState(out > as state_info), where state_info is an array of two strings - a key-value > pair. Keys could be IDLE, UPDATING, and FULL_INDEX. The IDLE value should be > ignored. The value of UPDATING is either the empty string or a string > formatted integer denoting how many % the update is done (at 100% you should > change state to IDLE). The value of FULL_INDEX is the same as UPDATING. > IDLE, and UPDATING, should be self explanatory, FULL_INDEX is used when the > indexer is generating a new index from scratch. > >  - Add a StateChanged signal with signature StateChanged (in as state_info) > - see item just above for description of argument. > >  - Add a GetFieldNames(in s session, out as field_names) method to inspect > the names of all indexed fields. This is useful for runtime cluster > extraction and advanced UIs. > > > Undecided > -------------- > >   - Can we control remote searches and other search scoping entirely via > session properties? I think we can... I think the Beagle devs are the only > ones with real experience here though. If we can we can delay the exact > specification of those properties a bit. > >  - Add a method to introspect all supported session properties? In the light > of the item just above this might make sense. > I was at the discussions and agree with the above. Cheers, Jos</blockquote> <div> Unless, someone shouts out, I'll add the above mentioned changes to the spec tomorrow. More proposed diffs --------------------------------  - Rename the method "NewSession" to just "Session"  - Define dbus app name, object name, and interface names to be     - app name: org.freedesktop.wasabi.searcher     - object name: /org/freedesktop/wasabi/searcher/main     - interface: org.freedesktop.wasabi.search Why those names then? I like to call the app/object "searcher", because it's kinda closer to the Lucene IndexSearcher object naming, and that it has more of an application feel to it (instead of just ".search"). I add /main to the object path for future extensibility. interface name - since the wasabi spec compliance level is stored in a session property we don't need version hinting in the interface name. Coding ----------- I'm writing my python based tools (for searching + dummy server), and things are progressing nicely. My hopes is that they can be used as a toolkit binding proposal too (api wise). Code will be up in this week. Cheers, Mikkel </div> </div>