> I had been assuming BSF would be used to define how a new processor > works. Right now we only have the LinearProcessor, which is defined a > linear set of matcher/mailet pairs using XML. Nothing to do at all with > per-user processing.
Yeah, some kind of imperative programming of processors has been a regular, if infrequent, request. And if we're going to embed a scripting language this would appear to be a good place to use it. > Yeah, I was thinking Sieve could be another kind of processor. For both > BSF and Sieve, I was thinking you could define your matchers and mailets > at the top of the processor with XML (like how you config servlets), and > then use either BSF or Sieve to define the flow-control logic. While I > think the extensibility is great, the flow-control logic with > LinearProcessor is very limiting. Either BSF or Sieve would also let > lots of "basic" matching and mailets to happen without needing to create > code. I like the idea of using seive, it looks cool, to define matchers. Perhaps even having a single seive matcher which could take the sieve code as a parameter (assuming we're going to allow parameters for matchers in Mailet3) > I haven't seen any implementations in the Java land... unfortunately > most of these mail server-side things (including maildir, mdox, > server-tailored javamail), etc... are all things (to my knowledge) we'll > have to build ourselves. I know Eyebrowse can read maildir, and Danny > said he knew someone who did a Java implementation of maildir, but I've > yet to find very many people doing open source server-side mail stuff > (outside of James). Yeah I found at least two java implementations of common mail file formats, but I'd have to trawl my notes to see if I can find them again. There would be a risk of reducing performance if we use a 3rd party implementation, for exactly Serge's reason that few people seem to be working on "server" Java Mail servers, most of the mail server stuff I've seen is actually intended to provide powerful mail handling for personal users, kind of personal mail servers (one reason I would like the Mailet API to be more easily portable, to allow these projects to implement it for filtering and repositories). Not only that but also most mail file formats I've looked at seem to be designed with simplicity in mind. Frankly I'd prefer us to build a file repository interface (based upon a generic MailetAPI repository interface) and implement a few file formats, and encourage contributions in a way similar to that in which we extend RDBMS support through contributions made easy by the seperation of concerns. Anyhow I'm too busy to breathe at the moment. :-) d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
