Back onto the list...
On Tue, Nov 23, 2004 at 11:27:54AM +0100, Andreas Aardal Hanssen wrote:I am not sure that the authors envisioned anything more than stuff that looks like email (such as news groups), but they did intend to separate separate storage mechanics from the access mechanics.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? :)
I too have been quite busy, hence the late reply to this message (but I have been thinking about this).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.
I say that IMAPdir (but not Maildir++) should be extended. My recollection of our discussions about the design of IMAPdir is that it was supposed to be the "new "depot" which implements something quite general", but that discussions of extensions would be deferred until after a solid implementation of the current IMAPdir had been implemented (thanks Andy)...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
<DESIGN_IDEA>
Extend IMAPdir so that folders that are executable files (instead of directories) get executed when accessed. We need to design an interface for these executable files (hereafter call programs) that implements all the IMAP verbs for message manipluation on the server; of course those verbs that make sense for the folder could be implemented as no-ops. We should also speficify a protocol for how to use local storage for those applications that require local storage, since we don't want the IMAP server think that the local storage is a mbox or a Maildir.
</DESIGN_IDEA>
I don't think this would be difficult to implment in Binc. It will probably be more difficult designing and programming well behaved programs (what are we going to call this programs? IMAPhandlers?).
In the case of the SPAM classification problem:
1. A filter in the Binc execution chain could create links
to the IMAPdir_learn_spam and IMAPdir_learn_ham programs.
2. Binc then sends the message to the standard input of
'IMAPdir_learn_spam COPY' when every a message is moved
to the LEARN_SPAM folder.
3. An 'IMAPdir_learn_spam EXAMINE' might be interpreted to
mean list all the rules or addresses that have been
blacklisted.
4. An 'IMAPdir_learn_spam STORE 2 +FLAGS (\Deleted)' followed
by an 'IMAPdir_learn_spam EXPUNGE' might be interpreted to
mean delete the rule or blacklisted address.Just my thoughts :-)
Henry
* Yes. see the design idea.Questions:
* Should it be possible to mix different folder types in one account?
* How does IMAPdir handle this currently?* Based on file information.
* See the design idea.* Use placeholder indicators inside IMAPdirs to create "virtual" folders using special depots?
* I don't understand this question.* Perhaps tone down the depot concept/class in favor of a folder concept/class?
..mh.. This will be fun. :)
//Peter
-- Henry Baragar Instantiated Software Inc. http://www.instantiated.ca
