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

List:       kde-pim
Subject:    Re: [Kde-pim] [RFC] Akonadi design
From:       "Vinay Khaitan" <vkhaitan () gmail ! com>
Date:       2006-05-16 6:29:54
Message-ID: 56c534770605152317p33d4185fkcc59e855da544a2f () mail ! gmail ! com
[Download RAW message or body]

Some comments on ongoing discussion:-

1) The storage basic query protocol is rudimentry, hence it is definite that
there would be large data transfer between search provider process and
storage process(easily going beyond GBs). Let's think about a scenario.
Type text/x-mail will provide all the mail which are stored. It easily goes
beyond GBs. Is it efficient?
It is quite better that search provider would like to see all the data but
in a more smart fashion. That means query all the text/x-mail and return all
the metadata.
Now depending upon metdata, it will select specific UID of mails and query
all those UIDs only. This problem and solution is not specific to mails but
to all the other PIM datatypes.
Any new extension would require to provide metadata+data to mimetype. So
this design would also remain extensible.

2) Have we thought about network scenario? I mean storage process/Search
providers would be running on different machine and queries are done by
clients from other machine? It looks like current design fits with this
scenario IMHO.

3) We have to decide between, do we want to allow application level
configuration or only resource level configuration. former one would vary
from client to client and later one would unify them essentially making
change to one client(actually this is a change to resource configuration) to
propogate to other clients.
As far as resource configuration GUI is concerned, we can leave it to
clients and provide only protocol to resources which will be utilized by
clients(in the scenario of not allowing client level configuration).

4)........more later.


On 5/15/06, Tobias Koenig <tokoe@kde.org> wrote:
>
> On Sat, May 13, 2006 at 02:17:26PM +0200, Volker Krause wrote:
> > On Saturday 13 May 2006 11:56, Tobias K˙fffff6nig wrote:
> Hi Volker,
>
> > I meant filters in the sense of kmail's filtering system, not in the
> sense of
> > "view filters" or virtual folders.
> >
> > Filters in the kmail sense basically mean operations you want to perform
> on
> > incoming items, such as moving them into a diffrent folder, tagging them
> or
> > running mails through spamassassin.
> These filters are only applyed to incoming (incoming as downloaded from
> pop3/imap server) messages?
> In this case they should be part of the pop3/imap resource and the
> 'filtered' mails shall be stored in the storage.
>
> > That's maybe not a mandatory feature of the backend for now, but IMHO
> > something we should keep in mind.
> Yes of course.
>
> Ciao,
> Tobias
> --
> Separate politics from religion and economy!
> The Council of the European Union is an undemocratic and illegal
> institution!
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFEaHYHSvFUKpY6VLARAg9gAJwKLzPkx9JY8dOxx6vobMcTQOM1AwCgi3mK
> Fy+kurndnQEvLt2Lonrcpcs=
> =whhL
> -----END 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/
>
>
_______________________________________________
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]