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

List:       kmail-devel
Subject:    Re: KMFolder rework.
From:       Don Sanders <sanders () kde ! org>
Date:       2002-09-11 8:13:18
[Download RAW message or body]

On Wednesday 11 September 2002 15:49, Zack Rusin wrote:
> Hi guys,
>
> I wanted to discuss with you the new KMFolder for 3.2.
> So at first problems with the current approach:
> 1) two different codepaths for different folders, also known as the
> much hated "if ( folder->protocol() == "imap" )",
> 2) confusing relationship between kmfolernoder, kmfolder,
> kmfolderdir, kmfolderdirmgr,
> 3) asynchronous access only to imap ( which creates #1 ),
> 4) inability to add additional message storage backends without
> substantial changes to KMail's core.
>
> Right now I want to briefly discuss the basic idea and get in more
> depth as people starting asking question, identyfing problems,
> coming with suggestions.
>
> 1) All folders should become factories for respective asynchronous
> KMFolderJobs, which should work in a similar manner to the way
> KMImapJob does right now, so instead of different codepaths we'd
> always have:
> KMFolderJob *job = protocol->createJob( msg, tGetMessage );
> connect( job, SIGNAL(messageRetrieved(KMMessage*)),
>                this, SLOT(slotMsgTransfered(KMMessage*)) );
> connect( job, SIGNAL(finished()),
>                this, SLOT(slotJobFinished()) );
> job->start();
> The KMImapJob would be changed to more-less follow the interface
> provided by KMCommand.

Dattaway. Smart move Zack, very smart move :-)

> Also note that with this approach we can
> keep a list of performed actions and have an actual 'tasklist' with
> pending actions which users could stop/pause/delete (those of you
> who ever used Pan newsreader know what I mean, those who never did
> :
> http://pan.rebelbase.com/screenshots/task-manager.png ).
> 2) I want to provide a new base class looking more less as follows:
> class KMFolderPlugin : public QObject
> {
>   Q_OBJECT
> public:
>   KMFolderPlugin( KMAccount *parent = 0L, const char *name = 0L );
>   virtual ~KMFolderPlugin();
>
>   virtual void init( QPtrList<KMMessage> msgList )=0;
>   virtual void unload()=0;
>   virtual const char* id() const;
> public slots:
>   virtual void retrieveMessage( int idx ) =0;
>   virtual void retrieveMessage( KMMessage *msg ) =0;
>
>   virtual void storeMessage( KMMessage *msg )=0;
>   virtual void removeMessage( int idx )=0;
>   virtual void removeMessage( KMMessage *msg )=0;
> signals:
>   void messageRetrieved( KMMessage*, bool );
>   void messageStored( KMMessage*, bool );
>   void messageRemoved( KMMessage*, bool );
> };
> This interface isn't finished yet. I'd like to see what others
> think behavior should be exported to this class. QPtrList
> operations would also be required. I also would want to add
> KMVFolder class creation to KMFolderPlugin. KMFolderPlugin would
> ultimately act as the KMVFolder manager. Meaning ultimately all
> messages are held within
> KMFolderPlugin, but on a GUI level messages can be stored in
> KMVFolder's.

Okay, my implementation of vFolders on one of my many local branches 
at home implements virtual folders as a simple list of serial numbers 
(and TODO, a search expression member variable. Search expressions 
have to be factored out of the search dialog and into a common class 
for this)

I intend to update vFolders incrementally as new mail is discovered, 
or deleted. (So new mail comes in
  for each vFolder apply search conditions for that vFolder
    if new mail matches then
      add to that vFolder 
        (which just means adding a new serial number to the 
         list of serial numbers)

So the list of serial numbers is a cache, and if the cache is 
accidentally deleted by a luser then it can be regenerated by 
applying the KMVFolder search expression globally for all folders.

This KMVFolder class inherits from KMFolder like the other folder 
classes do. One problem is that I don't want to use mMsgList. 
KMVFolder is almost a proxy class. And it's a bit ugly to have a 
KMFolder class that doesn't need a mMsgList, it should be simpler 
than it currently is. And how to clean that up properly I'm not sure 
yet I was going to talk to Sam about that when we fully implement 
vFolders.

Okay what I'm trying to get to is that I don't see why vFolders 
especially should be a KMFolderPlugin. What's special about vFolders 
that requires that? I think it only makes sense for vFolders to be 
made a KMFolderPlugin if all KMFolder derived classes are made 
KMFolderPlugins.

Now it seems to mean that the interface you've given above is not the 
right one to be used for KMFolderPlugins. For that kind of interface 
we need everything in KMFolder, and then some extra even for stuff 
that isn't in KMFolder yet but should be because it's required for 
IMAP.

So the correct interface for KMFolderPlugin would be KMFolder after we 
get rid of all the protocl == "imap" in the code and factor that into 
KMFolder.

Don.

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]