2006/11/28, Jamie McCracken <[EMAIL PROTECTED]>:
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
DBus activation does not solve the problem of finding the right search
engine for a particular query. The vision of having many different
search providers, where the disk indexers are the most important ones,
is one that requires this.
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.
True.
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
What do you mean with 'dynamic interfaces'? We are not talking about
interfaces that change, but about busses that will have a dynamic
number of objects.
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
I see no value in a PrepareQuery method. If the search engine has a
need for caching, it can use the query as an ID. The functions
ExecuteQuery and QueryHitCount are contradictory. The first one is
asynchroneous and the second one synchroneous.
signal QueryHitAdd (ID i, uri s)
signal QueryHitRemove (ID i, uri s)
For performance reasons, these queries should return multiple URIs at once.
The above is easy to implement and should cover the simple ground
True, but I dont think it is radically different from the interface
that has been discussed before. Please have a look at what's there now
and help to build on that.
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)
They could be separate methods, but the requirements are also
adequately covered by the current proposal.
Cheers,
Jos
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
