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

List:       kde-pim
Subject:    Re: [Kde-pim] [RFC] Akonadi design
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2006-05-18 9:46:31
Message-ID: 200605181146.31863.schumacher () kde ! org
[Download RAW message or body]

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.
> I favor the latter solution, but I don't see the real difference between> letting \
> the resources do the filtering of new messages (possibly using> a private \
> "unfiltered" folder).
The difference would be that the data still is available to other clients.
> Moreover, I want to mention that we currently have POP filters. Those> will \
> definitely have to be dealt with by the POP resource. And the POP> filtering will \
> sometimes have to show a dialog.
That would be some kind of notification. We definitely need a way for clients to send \
messages to other clients which are then could be shown in a dialog.  We probably \
even need a way to have some GUI interaction with a client from another client, e.g. \
for conflict resolution. So the user could interact with the POP client from within \
                KMail.
-- Cornelius Schumacher \
<schumacher@kde.org>_______________________________________________kde-pim mailing \
listkde-pim@kde.orghttps://mail.kde.org/mailman/listinfo/kde-pimkde-pim home page at \
http://pim.kde.org/


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