2006/11/19, 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;"> Hi Mikkel, Yes, the common dbus api is still something we need. I wanted to start on the metadata standarization first, but we can do the searching api in parallel. You make a good start in listing the available engines. There might even be more. To coordinate we need a process that lists the available search engines over dbus. An application should be able to say: I want to search using a particular interface with the available search engines. </blockquote><div> Agreed, that we need a dead easy way to get a list of search providers. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The attached archive contains an effort to do two things: - propose a very simple, common api for search engines - implement such a coordinating daemon   The code contains the daemon, a demo search application and a python client to access it by finding the search engine over the searchmanager.</blockquote><div>  Great work. I like your dbus api docs! </div><div> 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'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... </div> Of course if there are good arguments for a daemon then I'm willing to reconsider... :-) 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. 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? [1:] Type text in entry: net Get a popup with:             net   (7801)             network (6578)             netto (17) 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 ) each string in the groups array should belong to fx:         "Files"         "Folders"         "Documents"         "Images"         "Audio"         "Videos"         "Development Files"         "Conversations"         "Playlists"         "Applications"            "Contacts"         "Emails"            "EmailAttachments"         "Notes"         "Appointments"         "Tasks"         "Bookmarks"         "History"         "Projects" How about live queries? Maybe that should be supported in another interface than the simple one. 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. I'll have a closer look at your work and follow up tomorrow. Cheers, Mikkel <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The proposal for the search api is _very_ simple and I call for application developers to see if the function calls in there are sufficient. Here i paste them for convenience: interface org.freedesktop.search.simple method startConfiguration ( ) Open a graphical interface for configuring of search tool. method countHits ( in s query , out i count ) Count the number of instances of a file that match a particular query. Input: query     The query being performed. Output: count     The number of documents that match the query. method query ( in s query, in i offset, in i limit , out as hits ) Perform a query and return a list of files that match the query. Input: query     The query being performed. offset     The offset in the result list for the first returned result. limit     The maximum number of results that should be returned. Output: hits     A list if filenames that are the result of the query. method getProperties ( in as files,in a(sa(sas)) properties ) Get properties for the given files. Input: files     A list of files for which properties should be returned. properties     The properties belonging to each file. Each property is a name associated with a list of string values. The index of each property map in the list corresponds to the index of the filename in the list of files. 2006/11/3, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>>: > > 2006/10/30, Jos van den Oever < > > > > jvdoever at <a href="http://gmail.com">gmail.com</a>>: > > > > > To make it a bit more concrete (yes, you're probably not running > > > strigi svn) here's some code that generates the xml output using > > > kde3's metadata framework. I'm sure doing the same for other programs > > > > > > > is easy too. Then comes the hard task: making it all consistent. > > > > Here's already a new version of the kde3 code. I forgot to escape the > > special xml entities. > > It's probably a good idea to open up a project in svn for this stuff. > > > > > > If there's enough interest about it, that is. Can someone arrange > > that? The testcases should also go in there. > > > > Cheers, > > Jos > > > >  Picking up the track from Gnome d-d-l I am interested in hearing if your > are also looking into a unifying dbus api for desktop indexers? Being a > deskbar developer I am greatly interested in this part of a potential spec. > > > If you are more on the metadata extraction part of it now (as it would seem) > I can try and make an overview of the current available apis, and try to > make some form of synthesis we can use as a base for further discussion... > > Cheers, > Mikkel > > > PS: What indexers are around (and actively developed/maintained, and > actually has working code): > >  - Tracker <a href="http://www.gnome.org/~jamiemcc/tracker/">http://www.gnome.org/~jamiemcc/tracker/</a> > >  - Beagle <a href="http://beagle-project.org/">http://beagle-project.org/</a> >  - Strigi > <a href="http://www.vandenoever.info/software/strigi/">http://www.vandenoever.info/software/strigi/</a> >  - Pinot <a href="http://pinot.berlios.de/">http://pinot.berlios.de/</a> >  - GLSCube <a href="http://www.glscube.org/"> http://www.glscube.org/</a> >  - Nepomuk > <a href="http://nepomuk-kde.semanticdesktop.org">http://nepomuk-kde.semanticdesktop.org</a> (do > they have any code?) > > _______________________________________________ > xdg mailing list > <a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/xdg">http://lists.freedesktop.org/mailman/listinfo/xdg </a> > > > </blockquote></div>