[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] [RFC] SearchProvider for Akonadi
From:       Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2006-09-11 19:58:08
Message-ID: 200609112158.22253 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 06 September 2006 14:17, Volker Krause wrote:
> On Wednesday 06 September 2006 11:06, Tobias Koenig wrote:
> > The questions I have are:
> >
> >    1) Should a search result always be stored in a collection in
> > the storage or should the results be returned by a dcop signal?
>
> I don't see a use-case for immediately returned results yet because
> they don't support live updates, which is something we probably want
> to have everywhere.

Moreover, it would be nonsense to force the clients to implement two 
different ways of handling results.

> >    2) Do we need a 'or' combination in the search querys? If yes,
> > that makes the whole thing more complex, because we have to add
> > priority checks then...
>
> IMHO yes (eg. search all mail which are unread or have the todo flag
> set). To keep it simple we might want to just support one global
> and/or as it is done in KMail but no nesting. Also, a "isElementOf"
> operator to test if a flag/attribute/category/etc. is in a given set
> might help to remove the need of nested and/ors (eg. all mails on
> kde-pim which are unread or todo).

Yes, we definitely need 'or'.

> > SearchProvider:
> > ----------------
> >
> > General concept:
> >
> >  - simple (mimetype independend) searches are done by the storage
> > directly - extended (mimetype/data specific) searches are done by
> > the search provider
> >
> >
> > API of SearchProvider:
> > [...]
>
> The API looks good to me.

Except for the Comparators enum. This might be rich enough for 
kaddressbook's needs but it's way too limited for what we have in 
kmail. I don't think we should use an enum for this because an enum is 
not extensible. I think we should use a QString instead. This way 
people can write new search providers implementing searches we would 
have never thought about. The search providers should then return a 
list of supported mime-types + supported criteria.

Later the search manager might even call different search providers for 
a complex search and then create the final result of the search from 
the returned results of the different search providers. But first we 
should make it work with a single search provider.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]