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

List:       kde-pim
Subject:    Re: [Kde-pim] [RFC] Akonadi design
From:       Till Adam <adam () kde ! org>
Date:       2006-05-18 10:07:40
Message-ID: 200605181207.41364.adam () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 18 May 2006 11:46, Cornelius Schumacher wrote:
> On Thursday 18 May 2006 11:16, Ingo Klöcker wrote:
> > Am Donnerstag, 18. Mai 2006 10:29 schrieb Cornelius Schumacher:
> > > Wouldn't it be cleaner to have the filters as a separate client?
> > > So the POP or IMAP clients just puts data into the storage, the
> > > filter filters it from there and KMail or any other client then
> > > accesses the filtered data?
> >
> > How would that work? Let's say a new message arrives in the IMAP
> > inbox. Akonadi informs all clients, i.e. the filter client and
> > KMail, that there's a new message in the inbox. The filter client
> > will then process this message and move it to folder foo. Then
> > Akonadi will inform all clients that a message vanished from inbox
> > and appeared in folder foo. That doesn't sound like the way to go.
>
> I think we need a notification subscription mechanism anyway, so
> KMail would not get the notification from the IMAP inbox.
>
> > Alternatively, all unfiltered messages would have to be put into an
> > unfiltered folder (one per resource) which is hidden from normal
> > clients, i.e. from all clients but the filter client. (I wanted to
> > implement a similar solution for a long time already, i.e. first
> > download all messages from a POP server to a special folder and
> > then filter them because this would have made KMail much more
> > robust against losing messages which have already been downloaded
> > and deleted from the POP server, but which are still stuck in the
> > filter.)
>
> That would basically be what I meant with subscribing to
> notifications from the filter, but not to the raw POP data.

Maybe some kind of a proxy-model-like approach would work, where the 
interface (KMail) receives notifications from a proxy (the filtering 
agent) instead of the real store transparently?

Just a wild idea, haven't really thought about it in detail.

Till

[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]