2007/1/6, Jean-Francois Dockes [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen writes:
2006/12/24, Jean-Francois Dockes [EMAIL PROTECTED]:
Oops, yes, you're right the URI can change too.
Whether an uri can change or not is merely a matter of definition. If
an object changes uri it
To put matters short: You agree with Magnus' proposal 2 in the thread
Simple ssearch API proposal, take 2?
To put matters short :) yes
I also agree with you that it might be better to have an opaque string as
search identifier, this doesn't change anything for the application and
gives more
Mikkel Kamstrup Erlandsen wrote:
2007/1/1, Thiago Macieira [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen wrote:
Currently the live interface proposed in
http://wiki.freedesktop.org/wiki/WasabiSearchLive has the three
signals Query.{HitsAdded, HitsRemoved, HitsModified}. The argument
passed
(Resending with CC to xdg list. Now I have been bugged out on diseases
for a couple of weeks and have to apologise for the late replay.)
Sorry for the late reply I've been totally bugged out on diseases and
work! Here goes :-)
Because of the long nature of this mail I summarize some
2006/12/31, James Doc Livingston [EMAIL PROTECTED]:
On 31/12/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
If an object changes uri it might as well be regarded as another object
all together. The end user will see it as a rename/move but in the api I
think we should go for the
2006/12/31, Jamie McCracken [EMAIL PROTECTED]:
James Doc Livingston wrote:
URIs not being able to change and being a 1:1 mapping makes some things
easier, like not having to retrieve the URI for all the hits. On the
other hand, it means that any application that wants/needs persistent
James Doc Livingston wrote:
On 31/12/06, *Mikkel Kamstrup Erlandsen* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
2006/12/24, Jean-Francois Dockes [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Oops, yes, you're right the URI can change too.
Whether an uri can change
2006/12/24, Jean-Francois Dockes [EMAIL PROTECTED]:
James \Doc\ Livingston writes:
On Thu, 2006-12-21 at 19:07 +0100, Jean-Francois Dockes wrote:
About 2), URI *is* an appropriate handle, and probably the best as
long as
we can't guarantee the stability of the result set (that is: *if* we
On 31/12/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
2006/12/24, Jean-Francois Dockes [EMAIL PROTECTED]:
Oops, yes, you're right the URI can change too.
Whether an uri can change or not is merely a matter of definition.
I agree, but it is fairly important which way around the
James \Doc\ Livingston writes:
On Thu, 2006-12-21 at 19:07 +0100, Jean-Francois Dockes wrote:
About 2), URI *is* an appropriate handle, and probably the best as long as
we can't guarantee the stability of the result set (that is: *if* we need
separate Query() and GetSnippets() calls,
2006/12/21, Jean-Francois Dockes [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen writes:
Having a unique handle for each document is a really handy thing. A
unique
handle could be many other things than an uri, fx a unique integer or
anything as well. The way you describe this handle is just a
On Thu, 2006-12-21 at 19:07 +0100, Jean-Francois Dockes wrote:
About 2), URI *is* an appropriate handle, and probably the best as long as
we can't guarantee the stability of the result set (that is: *if* we need
separate Query() and GetSnippets() calls, *then* the URI is probably the
best
Mikkel Kamstrup Erlandsen writes:
2006/12/19, Jean-Francois Dockes [EMAIL PROTECTED]:
Especially, returning the initial result as a sequence of uris (presumably
ordered by relevance), and then using them as keys to retrieve properties
is very awkward on the server side (forces
As an afterthought to my previous message (sorry), the result list could
change if the query has to be re-run. This is a good reason for keeping the
uris as document identifiers for getSnippets().
jf
Jean-Francois Dockes writes:
Mikkel Kamstrup Erlandsen writes:
2006/12/19, Jean-Francois
2006/12/20, Jean-Francois Dockes [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen writes:
...
I think you are quite right. Except that maybe the output parameter of
simple.Query should be a{sa{sas}} - a map mapping uris to maps of
property-valuelist pairs. The trick is that metadata fields can
By the way, I had a go at implementing the simple api, just to get myself
better acquainted with dbus.
I still think that a trivial interface may be useful. The current one makes
things unnecessarily complicated in my opinion.
Especially, returning the initial result as a sequence of uris
On Sat, 2006-12-16 at 17:53 -0800, Bastian, Waldo wrote:
John,
See the reference below to DBUS sessions. Doesn't DBUS have the ability
to inform any client about connects and disconnects of other clients to
the bus?
So yes, you can track any service on the bus by simply listening for
Bastian, Waldo wrote:
See the reference below to DBUS sessions. Doesn't DBUS have the ability
to inform any client about connects and disconnects of other clients to
the bus?
It does. Any connection or disconnection is immediately notified to the
bus.
--
Thiago Macieira - thiago (AT)
At the risk of stating the obvious, but why not just use SQL?
select files.filename from files,tags tag1, tags tag2 where files.id =
tag1.fileid and files.id = tag2.fileid and tag1.key=artist and
tag1.value=foobar and tag2.key=group and tag2.value=audio
It seems that all the API is
2006/12/17, John Tapsell [EMAIL PROTECTED]:
At the risk of stating the obvious, but why not just use SQL?
select files.filename from files,tags tag1, tags tag2 where files.id =
tag1.fileid and files.id = tag2.fileid and tag1.key=artist and
tag1.value=foobar and tag2.key=group and
Mikkel Kamstrup Erlandsen wrote:
2006/12/17, John Tapsell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
At the risk of stating the obvious, but why not just use SQL?
select files.filename from files,tags tag1, tags tag2 where files.id
http://files.id =
tag1.fileid and files.id
Jamie McCracken wrote:
Thiago Macieira wrote:
Bastian, Waldo wrote:
See the reference below to DBUS sessions. Doesn't DBUS have the
ability to inform any client about connects and disconnects of other
clients to the bus?
It does. Any connection or disconnection is immediately notified to
PROTECTED] [mailto:xdg-
[EMAIL PROTECTED] On Behalf Of Jamie McCracken
Sent: Friday, December 15, 2006 6:12 AM
To: Mikkel Kamstrup Erlandsen
Cc: xdg@lists.freedesktop.org
Subject: Re: simple search api (was Re: mimetype standardisation by
testsets)
Mikkel Kamstrup Erlandsen wrote:
Question 1
Mikkel Kamstrup Erlandsen wrote:
Question 1 : Will it benefit the search engine to have a Session object
for each connection? Then Query objects are spawned by a call like
Magnus suggest; Query = NewQuery(Session, query_string)? Is it correct
that applications doesn't need to care about
2006/12/3, Joe Shaw [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen wrote:
Just a quick idea,
How about using JSON (www.json.org http://www.json.org) as to
represent the query objects (instead of xml)?
I'm reluctant to do this because I'm not sure how comprehensive the
stacks are for C#. The
2006/12/3, Jos van den Oever [EMAIL PROTECTED]:
2006/12/3, Joe Shaw [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen wrote:
Just a quick idea,
How about using JSON (www.json.org http://www.json.org) as to
represent the query objects (instead of xml)?
I'm reluctant to do this because I'm
2006/12/3, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/12/3, Jos van den Oever [EMAIL PROTECTED]:
2006/12/3, Joe Shaw [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen wrote:
Just a quick idea,
How about using JSON ( www.json.org http://www.json.org) as to
represent the query
2006/12/3, Jos van den Oever [EMAIL PROTECTED]:
if we dont allow for nested queries, a query can be defined as a(iss)
which is a list of query arguments.
i - query operator: +, -, , or
s - name of the field to search in
s - value to look for
Ok, so fx:
{
{+, content, foo bar}
}
Searches
Just a quick idea,
How about using JSON (www.json.org) as to represent the query objects
(instead of xml)?
It is light, easily readable, widespread, and there is possibility to write
extremely fast parsers.
Cheers,
Mikkel
___
xdg mailing list
Hi,
Mikkel Kamstrup Erlandsen wrote:
Just a quick idea,
How about using JSON (www.json.org http://www.json.org) as to
represent the query objects (instead of xml)?
I'm reluctant to do this because I'm not sure how comprehensive the
stacks are for C#. The XML stacks we have -- the built in
2006/11/30, Jamie McCracken [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen wrote:
2006/11/28, Jamie McCracken [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
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
On Sun, 19 Nov 2006 12:19:45 +0100
Jos van den Oever [EMAIL PROTECTED] wrote:
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
Hi,
On Thu, 2006-11-30 at 09:32 +0800, Fabrice Colin wrote:
On 11/30/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
Ok. My opinion is this:
Create a simple api for direct use. No live queries, just batch deliverance
and support for paging (much like the current spec on
2006/11/30, Joe Shaw [EMAIL PROTECTED]:
Hi,
On Thu, 2006-11-30 at 09:32 +0800, Fabrice Colin wrote:
On 11/30/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]
wrote:
Ok. My opinion is this:
Create a simple api for direct use. No live queries, just batch
deliverance
and support for
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
Mikkel Kamstrup Erlandsen wrote:
Why is it that you are against a dbus object per query? That way you
listen to signal on the object directly and avoid message filtering (and
possible flooding of the bus). More over a a dedicated object is also
easier to bind in the toolkits (as far as I
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
Jos van den Oever wrote:
Hi Jos,
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.
not sure - I just
Hi,
On Tue, 2006-11-28 at 14:46 +, Jamie McCracken wrote:
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'm not sure I totally follow you, but the
2006/11/29, Jamie McCracken [EMAIL PROTECTED]:
Mikkel Kamstrup Erlandsen wrote:
Why is it that you are against a dbus object per query? That way you
listen to signal on the object directly and avoid message filtering (and
possible flooding of the bus). More over a a dedicated object is
2006/11/28, Jamie McCracken [EMAIL PROTECTED]:
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
You mean that the client app will have to do dbus match
Mikkel Kamstrup Erlandsen wrote:
2006/11/28, Jamie McCracken [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
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
On 11/30/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
Ok. My opinion is this:
Create a simple api for direct use. No live queries, just batch deliverance
and support for paging (much like the current spec on WasabiSearchSimple).
The question on whether to standardize on a simple query
2006/11/28, Jos van den Oever [EMAIL PROTECTED]:
2006/11/28, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Hi,
On Mon, 2006-11-27 at 12:12 +0100, Jos van den Oever wrote:
Exactly. And having live queries is similar to this.
I'm not
2006/11/28, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/28, Jos van den Oever [EMAIL PROTECTED]:
2006/11/28, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Hi,
On Mon, 2006-11-27 at 12:12 +0100, Jos van den Oever wrote:
Exactly.
On Tue, 2006-11-28 at 07:15 +0100, Mikkel Kamstrup Erlandsen wrote:
I think everybody wants that (atleast I do). However the idea about
org.freedesktop.search.simple was to have a *simple* interface. Here
the simple only applies to the end user-app developers.
Yeah, I can certainly appreciate
2006/11/28, Joe Shaw [EMAIL PROTECTED]:
On Tue, 2006-11-28 at 07:15 +0100, Mikkel Kamstrup Erlandsen wrote:
I think everybody wants that (atleast I do). However the idea about
org.freedesktop.search.simple was to have a *simple* interface. Here
the simple only applies to the end user-app
2006/11/28, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/28, Joe Shaw [EMAIL PROTECTED]:
On Tue, 2006-11-28 at 07:15 +0100, Mikkel Kamstrup Erlandsen wrote:
I think everybody wants that (atleast I do). However the idea about
org.freedesktop.search.simple was to have a *simple*
Hi,
On Tue, 2006-11-28 at 19:11 +0100, Mikkel Kamstrup Erlandsen wrote:
I think I see where the disagreement comes from. Currently the premise
for the simple search api has been that it didn't need any language
bindings. Applications would certainly wrap the interface in a native
object
2006/11/28, Jos van den Oever [EMAIL PROTECTED]:
2006/11/28, Joe Shaw [EMAIL PROTECTED]:
On Tue, 2006-11-28 at 19:11 +0100, Mikkel Kamstrup Erlandsen wrote:
I think I see where the disagreement comes from. Currently the premise
for the simple search api has been that it didn't need any
Mikkel Kamstrup Erlandsen writes:
Let me gauge the current vibes to try an focus on where we are heading.
Hey, I have given no recent vibes. Let me vibe a little. I'm still much
with your original project.
?1) There is general consensus on forgetting about
org.freedesktop.search.simple as
2006/11/26, Kevin Krammer [EMAIL PROTECTED]:
On Sunday 26 November 2006 18:17, Jean-Francois Dockes wrote:
Jos van den Oever writes:
2006/11/26, Jean-Francois Dockes [EMAIL PROTECTED]:
1- A need for trivial enabling of text search in any (non-search)
application, with minimal
2006/11/27, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/26, Jos van den Oever [EMAIL PROTECTED]:
I'm not a d-bus expert, but at least with the qt4 bindings, it seems
that
you have a choice of waiting for the reply to a d-bus message, or be
called
later when it arrives. There
2006/11/27, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/26, Jos van den Oever [EMAIL PROTECTED]:
I'm not a d-bus expert, but at least with the qt4 bindings, it seems
that
you have a choice of waiting for the reply to a d-bus message, or be
called
later when it arrives. There
2006/11/26, Jean-Francois Dockes [EMAIL PROTECTED]:
It's quite amazing how parallel thinking can bring people to the same
point
over a few days. I am in quite complete agreement with Fabrice's message
and most of Wasabi2 or the recent edits by Mikkel on Wasabi.
The initial stated goal for
Mikkel Kamstrup Erlandsen writes:
- About the query language, and just for the record, the syntax described
on WasabiDraft is more the one from Beagle than the one from Lucene
(which defaults to ORing, not ANDing the terms I think). This is
probably and appropriately more intuitive for
On Sun, 2006-11-26 at 14:55 +0100, Thiago Macieira wrote:
James Doc Livingston wrote:
This would work, as music players could search for files that have
audio/* and no video/* types. The only question is whether any/all of
the backend searchers do this, as it would make it awkward for what to
On Monday 27 November 2006 12:08, Mikkel Kamstrup Erlandsen wrote:
I am not a searching or indexing expert, merely wanted to input some
information regarding D-Bus sync/async calls :)
I think you raise a really good question Kevin. Let me first introduce
some terminology to ease the
Hi,
Sorry, I am just now catching up on this thread, I'm a little behind.
On Sun, 2006-11-19 at 12:19 +0100, Jos van den Oever wrote:
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
Hi,
On Sun, 2006-11-26 at 14:55 +0100, Thiago Macieira wrote:
If a file type is a container type, the indexer has to be smart enough to
look inside it. A good example are zip files, which can be OpenDocument
too.
Shouldn't this be the job of the MIME detection code instead? To
inspect the
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Sorry, I am just now catching up on this thread, I'm a little behind.
I'm glad you're joining. The users are getting the upper hand and
saying things like:
Again, some backends will have native caching capabilities, others
won't. I think we should focus
Hi,
On Mon, 2006-11-20 at 21:39 +0100, Mikkel Kamstrup Erlandsen wrote:
Given that it would be part of the search language it cannot be ruled
out of the simple api, unless we restrict the simple api to only
support a subset of the query language (which I don't think is a good
idea).
This
Hi,
On Thu, 2006-11-23 at 16:26 +0100, Mikkel Kamstrup Erlandsen wrote:
The situation at hand is that we have a handful of desktop search
engines, all implemented as daemons, both handling searches and
indexing.
Yeah, but this situation isn't realistic. The user should never be
running
Hi,
On Mon, 2006-11-27 at 12:12 +0100, Jos van den Oever wrote:
Exactly. And having live queries is similar to this.
I'm not the best person to propose an asynchronous language because
Strigi has only synchronous queries at the moment. If there's a good
API, i might change that
Hi,
On Fri, 2006-11-24 at 12:25 +0100, Jean-Francois Dockes wrote:
If we don't find an appropriate established language, I see at least two
options for a more structured approach:
- No query language: use a data structure representing the parsed query tree.
- Use an xml-based approach for
Hi,
On Mon, 2006-11-27 at 20:39 +0100, Jos van den Oever wrote:
I'm fine with an additional query function. I avoided this in the
first place because the return message would become rather big. How
about:
method queryDetailed ( in s query, in i offset, in i limit , out
a(sa(sas)) hits )
2006/11/27, Jos van den Oever [EMAIL PROTECTED]:
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Seriously, how does that work with the object paths? Do you mean make
each query into an object that can be accessed later on? Sounds good.
Yeah, you instantiate a Query object for each search, which
Joe Shaw wrote:
Shouldn't this be the job of the MIME detection code instead? To
inspect the container and say this is audio/x-vorbis+ogg or this is
video/x-theora+ogg ? That way it works correctly desktop-wide.
So, video/x-theora+vorbis+vob-subtitles+ogg ?
Hell, no. If a format allows for
Hi,
On Mon, 2006-11-27 at 23:02 +0100, Thiago Macieira wrote:
Joe Shaw wrote:
Shouldn't this be the job of the MIME detection code instead? To
inspect the container and say this is audio/x-vorbis+ogg or this is
video/x-theora+ogg ? That way it works correctly desktop-wide.
So,
Joe Shaw wrote:
There's no question about this. It's the indexer's responsibility to
extract the relevant information from the file, but fundamentally what
kind of file that is (again, think SVG vs. XSLT) is something the MIME
code should handle.
I think we're arguing for the same thing :-)
We
2006/11/27, Magnus Bergman [EMAIL PROTECTED]:
On Sat, 25 Nov 2006 21:49:22 +0100
Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
2006/11/24, Magnus Bergman [EMAIL PROTECTED]:
On Thu, 23 Nov 2006 16:26:31 +0100
Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
2006/11/22,
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Hi,
On Mon, 2006-11-27 at 20:39 +0100, Jos van den Oever wrote:
I'm fine with an additional query function. I avoided this in the
first place because the return message would become rather big. How
about:
method queryDetailed ( in s query, in i
On 11/28/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Wouldn't returning the full metadata (except snippets) for every single hit
be a costly affair? Maybe we need a parameter for which fields to return.
Agreed. Who knows how many metadata
2006/11/28, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
2006/11/27, Joe Shaw [EMAIL PROTECTED]:
Hi,
On Mon, 2006-11-27 at 12:12 +0100, Jos van den Oever wrote:
Exactly. And having live queries is similar to this.
I'm not the best person to propose an asynchronous language because
On Mon, 2006-11-27 at 14:33 -0500, Joe Shaw wrote:
Shouldn't this be the job of the MIME detection code instead? To
inspect the container and say this is audio/x-vorbis+ogg or this is
video/x-theora+ogg ? That way it works correctly desktop-wide.
As Thiago mentioned, this doesn't work very
On Sun, 2006-11-26 at 13:01 +0100, Thiago Macieira wrote:
The detection of M4A files as video/* is just plain wrong, OTOH. If it
doesn't contain a video stream, it mustn't be in video/*.
M4A files are audio inside a Quicktime container and the mime-type
assigned for Quicktime is
James Doc Livingston wrote:
This would work, as music players could search for files that have
audio/* and no video/* types. The only question is whether any/all of
the backend searchers do this, as it would make it awkward for what to
do to depend on the backend.
If they don't, they should
2006/11/26, Jean-Francois Dockes [EMAIL PROTECTED]:
1- A need for trivial enabling of text search in any (non-search)
application, with minimal fuss, (better described by Fabrice in the
quoted message).
For this, we also need a way to search in documents that have not been
indexed.
James \Doc\ Livingston [EMAIL PROTECTED] wrote:
This is actually the perfect example of why using mime-types for this
won't actually work: the mime types for Ogg Vorbis files and M4A files
are application/ogg and video/quicktime respectively, which are also
the mime types of video files in the
Dnia 24-11-2006, pią o godzinie 07:40 +0100, Mikkel Kamstrup Erlandsen
napisał(a):
2006/11/23, Patryk Zawadzki [EMAIL PROTECTED]:
But you can use object handlers just like you use file
handlers - let
the DBUS interface pass you a handle and use that handle when
2006/11/24, Fabrice Colin [EMAIL PROTECTED]:
On 11/24/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
2006/11/23, Fabrice Colin [EMAIL PROTECTED]:
What Magnus suggests may be useful for document 'sources' or 'groups'
(for
lack of a better name), eg Documents, Applications, Contacts,
On 11/24/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
The Wiki is clear enough. It's just that it may be useful to provide
the consumer
application with a list of supported groups... unless we dictate which
groups should
be supported by all engines.
Well, my idea was to come up
Here follow my impressions after reading the Wasabi Draft document.
Query language:
--
I think that the choice of using a google-like language is not good. This
kind of query language was primarily designed to be human-typable and have
not much else in their favour. If the Wasabi
On Fri, 24 Nov 2006 12:25:41 +0100
Jean-Francois Dockes [EMAIL PROTECTED] wrote:
Here follow my impressions after reading the Wasabi Draft document.
Query language:
--
I think that the choice of using a google-like language is not good.
This kind of query language was
Magnus Bergman writes:
On Fri, 24 Nov 2006 12:25:41 +0100
Jean-Francois Dockes [EMAIL PROTECTED] wrote:
[lots of query language ramblings]
I agree with everything above. By the way, it might also be useful
to be able to add weight to the sub-queries.
Something easily done with an
mikkel.kamstrup at gmail.com (Mikkel Kamstrup Erlandsen) writes:
magnus.bergman at observer.net (Magnus Bergman) writes:
One thing that English users seldom consider is the usages of several
languages. Which language is being used is important to know in order
to decide what stemming rules
2006/11/23, Jean-Francois Dockes [EMAIL PROTECTED]:
mikkel.kamstrup at gmail.com (Mikkel Kamstrup Erlandsen) writes:
magnus.bergman at observer.net (Magnus Bergman) writes:
One thing that English users seldom consider is the usages of several
languages. Which language is being used is
On 11/24/06, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote:
2006/11/23, Fabrice Colin [EMAIL PROTECTED]:
What Magnus suggests may be useful for document 'sources' or 'groups' (for
lack of a better name), eg Documents, Applications, Contacts,
Conversations etc... -as offered by some
2006/11/23, Patryk Zawadzki [EMAIL PROTECTED]:
Dnia 23-11-2006, czw o godzinie 20:44 +0100, Mikkel Kamstrup Erlandsen
napisał(a):
2006/11/23, Fabrice Colin [EMAIL PROTECTED]:
Well, AFAIK, dbus allows complex structures like arrays or
dictionaries.
Yeah, but that really
I invited the devs of all the listed projects (except spotlight and winfs)
to join the debate.
Cheers,
Mikkel
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Could you reword Count the number of instances of a file that match a
particular query. to Count the number of files that match a
particular query if I have understood that correctly.
On 19/11/06, Jos van den Oever [EMAIL PROTECTED] wrote:
Hi Mikkel,
Yes, the common dbus api is still
2006/11/19, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Could you reword Count the number of instances of a file that match a
particular query. to Count the number of files that match a
particular query if I have understood that correctly.
Yes, that is what is meant.
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
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 [EMAIL PROTECTED]:
2006/11/19, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED]:
Great work. I like your dbus api docs!
Thanks!
I must admit that I'm very keen on getting a
94 matches
Mail list logo
