You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/12/13 00:58:43 UTC
[V3] BSF and Sieve
Serge,
In what context did you raise the issue of a matcher (or whatever) needing
to split a Mail object with multiple recipients into multiple Mail objects?
Are you skipping ahead to the issue of per-user mail processing? Just to do
BSF, the Mail object could be exposed normally.
With respect to per-user processing, my thought is that we could have a
Mailet that looks at the recipient list and for each local recipient that
has per-user configuration, posts a message clone for that user. That way
we don't have do accommodate that behavior in all per-user matcher/mailet
code, or have a base class with per-user behavior.
But my initial reason for looking at BSF wasn't actually for per-user
scripts. It was to allow mail admins more options for writing custom
matchers/mailets.
Sieve looks interesting. Has anyone implemented it in Java? Regardless of
BSF integration, I could see how we might implement a SieveMailet. I don't
think that we should replace our pipeline architecture with Sieve. Instead,
if a site were to use Sieve extensively, they could simply have a smaller
pipeline.
I found GNU Sieve: http://www.gnu.org/software/mailutils/#sieve, and the
"real" libSieve project: http://libsieve.sourceforge.net/. I suppose that
we could look at porting the latter to Java.
Sieve is definitely something to discuss regarding v3, as it might have some
impact on the revised Mailet API.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Thursday, December 12, 2002 10:39
To: james-dev@jakarta.apache.org
Subject: Re: Back to square one with James
Noel J. Bergman wrote:
> For v3, I am hoping to introduce BSF so that matchers and mailets can be
> written in script languages.
Nice idea... I'm wondering how you could have a matcher (or whatever)
split a Mail object with multiple recipients into multiple Mail objects,
but otherwise I think that framework is a nice idea. There's also a
fledging IETF standard called Sieve that might be worthwhile looking at
for this (http://www.ietf.org/rfc/rfc3028.txt?number=3028)
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3] BSF and Sieve
Posted by "Noel J. Bergman" <no...@devtech.com>.
As I mentioned the other day, I found a copy of maildir implementations, and
was talking to one of the authors about James.
Will post more when we lift the v3 moritorium.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3] BSF and Sieve
Posted by Danny Angus <da...@apache.org>.
> If we can define a standard reference notation
> to these various repositories, we could build tools to migrate from one
> repository type to another,
If we make these repositories all obey a Mailet.Repository contract we could knock these kind of tools together fairly simply.
all we really need is list, add and remove. do we need lock and update?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [V3] BSF and Sieve
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> 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.
Cool.
> 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.
Yeah, on a related note, maildir is really not a very good format (from
a performance perspective) for a message repository with a lot of
changes. I think it became popular because it's easy to
read/interchange for users, but for most of the time, I don't think it's
necessary.
> 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.
I too would assume we build our own solid file repository. Once we
finalize the new mail repository interface, I'd like to build
implementations of newfile (our standard one, maybe based on Avalon),
oldfile (the old Avalon structure, mainly for porting), maildir, mbox,
jdbc, and imap-client. If we can define a standard reference notation
to these various repositories, we could build tools to migrate from one
repository type to another, including fun stuff like migrating all the
mail in user mailboxes from an old IMAP server into James.
Sorry, shouldn't be talking about this until we get the release pushed
out. I'll go proofread the docs this weekend as penance.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3] BSF and Sieve
Posted by Danny Angus <da...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [V3] BSF and Sieve
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Serge,
>
> In what context did you raise the issue of a matcher (or whatever) needing
> to split a Mail object with multiple recipients into multiple Mail objects?
> Are you skipping ahead to the issue of per-user mail processing? Just to do
> BSF, the Mail object could be exposed normally.
>
> With respect to per-user processing, my thought is that we could have a
> Mailet that looks at the recipient list and for each local recipient that
> has per-user configuration, posts a message clone for that user. That way
> we don't have do accommodate that behavior in all per-user matcher/mailet
> code, or have a base class with per-user behavior.
>
> But my initial reason for looking at BSF wasn't actually for per-user
> scripts. It was to allow mail admins more options for writing custom
> matchers/mailets.
>
> Sieve looks interesting. Has anyone implemented it in Java? Regardless of
> BSF integration, I could see how we might implement a SieveMailet. I don't
> think that we should replace our pipeline architecture with Sieve. Instead,
> if a site were to use Sieve extensively, they could simply have a smaller
> pipeline.
>
> I found GNU Sieve: http://www.gnu.org/software/mailutils/#sieve, and the
> "real" libSieve project: http://libsieve.sourceforge.net/. I suppose that
> we could look at porting the latter to Java.
>
> Sieve is definitely something to discuss regarding v3, as it might have some
> impact on the revised Mailet API.
>
> --- Noel
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.
My pontification was because in the Mail processing, if a matcher
"matches" only only a partial list of recipients, the processor has to
duplicate the Mail object and split the recipient list across the two
instances, according to who matched in the matcher. Theoretically,
matchers are supposed to be allowed to return a Collection of recipient
Collections, so then you would have to create triplicates, etc... of the
message.
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 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).
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>