simple search api (was Re: mimetype standardisation by testsets)

[Mikkel Kamstrup Erlandsen]

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 <jvdoever at gmail.com>:
>
> 2006/11/19, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> >  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061119/8dc5a1fc/attachment.htm