2006/11/19, Jos van den Oever <[EMAIL PROTECTED]>:
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.
Agreed, that we need a dead easy way to get a list of search providers.
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.
Great work. I like your dbus api docs!
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...
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
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 <[EMAIL PROTECTED]>:
> > 2006/10/30, Jos van den Oever <
> >
> > jvdoever at gmail.com>:
> >
> > > 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 http://www.gnome.org/~jamiemcc/tracker/
>
> - Beagle http://beagle-project.org/
> - Strigi
> http://www.vandenoever.info/software/strigi/
> - Pinot http://pinot.berlios.de/
> - GLSCube http://www.glscube.org/
> - Nepomuk
> http://nepomuk-kde.semanticdesktop.org (do
> they have any code?)
>
> _______________________________________________
> xdg mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>
>
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
