Re: kmailqueryable

[D Bera <dbera web gmail com>]

> > There are many mail-apps out there who store their mails in maildir
> > format (and some of them are hugely popular e.g. pine, mutt... -
> > widely used in academia where beagle is being extenstively to find
> > papers/mails/reports etc). Once KMail backend is in, there will be
> > requests to add their support too. The only difference between these
> > different applications is the location of mails, directory hierarchy,
> > naming conventions of the folders and some application specific
> > settings.
> 
> The bulk of the work for mail is done by the mail filter.  The crawler
> isn't a particularly interesting piece; it just looks in a certain
> directory.  The main differentiation is KMail-specific code, which is
> why it's more suitable as KMailQueryable.  We can add a MuttQueryable if
> there's a good reason for it.  In most cases, the filesystem backend
> should handle it.

Mostly true. However,
* There will be a hure repetition of code in each queryable -
regarding setting up inotify, crawler, etc.
* Dot-folders, tmp files, hidden-files are widely used in these
maildir stores. So, just cant handle every directory and file created
in the same way.
* Naming convention is different in different cases - and they store
the mail-folder name in different ways.

Conceptually, it looks to me like two separate entity - a minimal,
simple queryable which just checks the presence of a crawler and asks
the specific crawler (which would also be small - just informs the
queryable what to do with a new directory/file) what to do the files
and directories it sees. It would just look a bit cleaner and easily
extensible.

I will change the currently submitted patch in accordance to Fredrik's
suggestion if thats the preferred way.