Jos: CC'ing xdg, hope it's ok. I only follow up on the lib vs daemon part for now... <div>2006/11/19, Jos van den Oever <<a href="mailto:jvdoever@gmail.com">jvdoever@gmail.com</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2006/11/19, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com </a>>: >  Great work. I like your dbus api docs! Thanks! > I must admit that I'm very keen on getting a daemonless spec. There's > already atleast one daemon running for search purposes, and having another > on top of that seems overkill. I did take pains to write a daemon in C. This means it's very light. > I'd rather create library for finding search engines. This will require some > runtime negotiation but I don't think it will be a significant impact. I > have some rough ideas about a dbus api for this, I'll try and put it > together... In a library, how do you know which search daemons are running? You'd have to know where they are. With the searchmanager, there is always an up-to-date list because the managers register there. Even a new manager adhering to the interface would register and so it would be known.</blockquote><div> In a stateless lib you don't have to do any bookkeeping, the list of providers would be created when the app asks for it. Here's a short sketch of how I figure the workflow: App: calls lib.getSearchProvider (interface_name) lib: emit a SearchProvidersSpeakUp(iface_name) signal over dbus SearchProvider: return its object path to the lib lib: select a provider from the candidates if there's more than one lib: return candidates object_path App: dbus connect to iface, object_path </div> Does this make sense? What I really wanna do is push as much book keeping to dbus itself, since it already does a great deal of what we actually need... Cheers, Mikkel <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">About org.freedesktop.search.simple: > > org.freedesktop.search.simple.startConfiguration (): >  I would rather name it showConfiguration, but that is in the nit-picking > end of the debate. for a simple search interface I guess it is ok to have > coarse controls like this. A mote advanced interface could provide means to > set and get specific parameters on the search engine. Exactly. new definition: org.freedesktop.search.simple.showConfiguration () > org.freedesktop.search.simple.countHits ( in s query , out > i count ): >  Why is this necesary. Is it to accomodate use cases such as suggestion > popups like below[1], and reduce the dbus wire traffic for multiple calls? Not just that, it is also required for paging ( page 1, page 2, etc) and lines like 'Found X hits.' > Type text in entry: net > Get a popup with: >             net   (7801) >             network (6578) >             netto (17) No, this is another case. Here you see numbers for each keyword, but where do you get the keywords from? For something like that you'd need a call like: expandWord(in s word, out a(si) wordlist) > org.freedesktop.search.simple.query ( in s query, in i > offset, in i limit , out as hits ): >  What is the general consumer of this method? I don't see many. Only stuff > like deskbar-applet or a general search tool would use it. Maybe adding a > parameter to specify a list of groups the hits should match (or maybe > specifying mimetypes). This argument could be "*" or something to get all > kinds of results. I suggest changing the signature to: > query ( in s query, in as groups, in i offset, in i limit , out as hits ) Interesting suggestion. It does make things quite a bit more complicated. Because you'd need to define the groups. We've not talked about the query language yet ( we need to, but i'm assuming we're going to use something similar to what Beagle and Strigi already use, which is almost the same), but you also just expand the query like this: "holiday" -> "holiday mimetype:video/*" before sending it to the search-engine. That seems much better defined than a list of vaguely termed groups. I do not object to having such names for the user to see though. > How about live queries? Maybe that should be supported in another interface > than the simple one. Yes it should. Maybe we should try to get this running first. Live queries are rather tricky. > org.freedesktop.search.simple.getProperties ( in as > files,in a(sa(sas)) properties ): >  This seems good. It is a bit toward a metadata interface, but I think it is > good here to so apps don't need tons interfaces to work with. At some point > it there should be a specification on how to name and format these > properties/metadata. Small correction, it should be: org.freedesktop.search.simple.getProperties ( in as files,in a(sa{sas}) ) where one can argue about whether or not to send back the filename again. It's not needed, but also does not take much bandwidth. Cheers, Jos </blockquote></div>