Adam Lofts wrote:
Hi,
On 28/11/06, *Magnus Bergman* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Is it only realistic
that users would want (or should be able) to do such simple searches? I
think it's realistic to imagine that there can be different search
engines which are good at different things. Perhaps one is good at
finding media files by their tags. One that is good at finding relevant
information from fuzzy terms.
The multiple search engine problem seems to be the perfect use case for
dbus naming. Each search engine registers a well known unique name e.g.
"org.novel.Beagle.simple" and tries to own "org.freedesktop.search.simple".
Thus if I want to be picky about who to query I ask for the engine
specific name, and if I don't care (surely the common case) I ask for
the well known name. Wrapping a library around this would be fine, but
the main point of the spec needs to be defining this interface
("search.simple") and getting everyone to implement it.
On 28/11/06, *Magnus Bergman* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
At least I see it there has to be some kind of daemon if there is a
dbus interface.
Use dbus activation.
thats what I have been saying to mikkel (in private). We really dont
need a lib/daemon
Also I agree with most of what Joe Shaw has said on this thread
We should punt query language and metadata names to a later spec and
concentrate on getting a very simple implementation going first.
As for live queries, I dont like dynamic interfaces and in tracker we
will simply take a live_query_id as a param and use dbus signal
filtering to listen for changes to that specific ID
I would suggest having a PrepareQuery method which returns a unique
integer for the query then you can use that to :
1) Execute the query
2) Get the hit count
3) listen (using dbus match rules) for specific changes (hit added/removed)
Its simple and avoids bad practices like dynamically chanigning
interfaces (and is no less efficient)
Heres my suggested spec for Wasabi:
ServiceTypes is an array of service names like "Files", "Emails" etc
need to define full list)
method PrepareQuery (ServiceTypes as, query s) return ID i
method ExecuteQuery (int ID, offset i, limit i) return as (array of uri's)
method QueryHitCount (int ID) return i
signal QueryHitAdd (ID i, uri s)
signal QueryHitRemove (ID i, uri s)
The above is easy to implement and should cover the simple ground
For nautilus also needed is extra methods for searching files by mime
types and/or location - these can be separate methods as tracker
implements them (mime and location dont have a meaning with non-file
entities)
--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
