On Tue, Nov 23, 2004 at 11:27:54AM +0100, Andreas Aardal Hanssen wrote: > It certainly is a feature that opens a whole world of options for > sysadmins. If we had a similar script trigger for reading, emails > could be safely stored in bzip2 format, for example.
Yes. Another idea is to use Binc as an IMAP frontend for just about any other information store available programmatically. (Think forum stored in SQL database on web site, e.g.) This is actually what IMAP was designed for, isn't it? :) The more I think about this feature, the more I want it. Given some free time (which looks like March right now :( ) I'll back that up with code. ..in the future I see Binc being the host of all sorts of third-party modules, much like Apache today. Oh the possibilities! :) > But oh-oh, let's not dig into the details about that. It needs some > more high-level thinking first. Huge flexibility often backfires as > support requests to this list, and only the fact that we support it > could confuse novices. Default settings out of the box should undoubtedly be conservative, the current small setup effort should remain and ideally improve, but we should still be able to offer extensibility for power-admins. There are at least two ways to move forward, perhaps they should be pursued in parallell; 1. extend the Maildir++/IMAPdir depot backends with execve() hooks 2. create an all new "depot" which implements something quite general Questions: * Should it be possible to mix different folder types in one account? * How does IMAPdir handle this currently? * Use placeholder indicators inside IMAPdirs to create "virtual" folders using special depots? * Perhaps tone down the depot concept/class in favor of a folder concept/class? ..mh.. This will be fun. :) //Peter
