> > 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. _______________________________________________ Dashboard-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dashboard-hackers
