Danny Angus wrote: > On 1/5/07, Joachim Draeger <[EMAIL PROTECTED]> wrote: > > > > The best way would be a native, logical, hierarchical mailbox access > > through the Mailet API. > > If you would like to expand on this idea I'd be interested in seeing > what it looks like when applied to sandbox/mailet-refactorings/. If > you want to have a go yourself please do, otherwise talk about it and > I'll do something.
Let me first admit that due to lack of time I've not tracked the mailet-refactoring work, so I'm starting from a position of ignorance. Secondly, here is my 'blue sky' view of how things should be arranged... Mailets and Sieve are mail processing agents. They have very similar mail processing objectives and need access to the same mail and mail server resources. The key differences are: - A Mailet configuration is per server while a Sieve configuration is per user. - Mailets handle multiple recipients per invocation while Sieve handles a single recipient, the user. The differences are so small that a single Java API that exposes the mail server resources could cover each of their needs and other, yet to be invented, mail processing agents. Such an API could be used to expose the mail server resources of any mail server, even a non-Java based one using JNI and an async queue. On top of such an API we would add a layer with implementations of the mail processing agents, such as Mailets and JSieve. With such an arrangement JSieve would not need to be invoked as a Mailet. As discussed in 2004, JSieve would be configured as an additional James processor. The difference being from then to now, is the 'blue sky' option would use a James agnostic API. Getting back to reality, the best thing to do right now, is ensure that the Mailet API evolves to expose the resources needed for JSieve to run as a Mailet. This boils down to exposing all of the objects that an IMAP server surfaces that a Sieve script will act on. As I recall, over and above features previously discussed, this simply boils down to exposing a per user folder hierarchy and managing scripts on a per user basis. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
