Jos: CC'ing xdg, hope it's ok. I only follow up on the lib vs daemon part
for now...
2006/11/19, Jos van den Oever <[EMAIL PROTECTED]>:
2006/11/19, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>:
> 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.
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
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
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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
