Serge,
> As for the servlet-design thoughts, I think one of the biggest
> mistakes of the original servlet designers was believing they could
> design an API that could be used by multiple protocols. I started
> using the first preview of this spec 5 years ago, and 5 years later,
> the servlet API still hasn't found a second protocol that it can
> handle. Anyway, my point is I think newslets would be a great idea,
> but trying to make mailets able to handle both isn't really feasible.
Agree.
> I think the directions of Paul's email only underscore my point. I
> think the mailet API could stand to use some additions, like providing
> what this mail server's local users and hostnames are, and otherwise
> remove dependencies to Avalon that we have in core mailets and
> matchers. These kinds of additions to the API would tie mailets to an
> SMTP processing environment.
Err, actually I am advocating closer binding with Avalon-Framework
interfaces. It is what I have done for hot-installable Enterprise
Object Broker (EOB) jars. LogEnabled, Initializable, Startable,
Contextualizable, Configurable all have direct relevence to EOB-beans,
blocks, maillets and newslets. The difference for each is exhibited in
Contextualizable. Blocks are passes a Conext and cast them to
BlockContext, EOB-beans take a Context and cast them to BeanContext. I
see that working very well.
To supplement the Avalon-framework interfaces, I tagree that you of
course need mail-request/reply and news-request/reply interfaces for
strongly contracted mail/news event behaviour.
> I kind of like the mail concept of ".war"... I'd suggest we call it
> "mar" (mail application archive), but with Avalon we've already got
> sar and bar, and do we really need another ?ar filetype. :)
.mar would be good, but we learned a lesson with .bar in that .jar is
more accptable to developers as a concept. For EOB we have .jars with
EOB-INF/ manifests. We also have a .eob file that contains individual
eob-bean .jar files as well as a real .war if applicable (remember this
is a clean replacement for .ear files).
I'd suggest that individual maillets and newslets are in jar files and
you reserver your specially named zip for an application level concept.
There should be lots of borrowable code and concepts in EOB's Apache
licensed code.
> Anyway, and to your final points... isn't the mailet API already
> separated from James code? It's compiled to separate JARs. The two
> (minor) changes I have on tap for the next version of the mailet API
> are adding attributes to Mail objects, and log-levels to the logging.
> Renaming matchers to interceptors certainly makes it sound more
> comp-sci like, and that might help people used to looking at APIs
> understand what we're doing. Like I said above, we could stand to add
> other key concepts to the mailet context to support notions in SMTP
> processing.
>
> I know there's been yet another discussion of tying matchers to
> mailets, but I still don't like the results. First, most approaches
> tie us more to Avalon, which I'm against. Second, most approaches
> also tie a single matcher to a single mailet. Granted we've been
> unable to provide anything beyond this, I'm reluctant to have the API
> enforce this relationship because I think there are alternate ways to
> accomplish the integration betwen mailets and matchers without this tie.
I think if you move the APIs (multiple) for maillets etc further from
Avalon-Framework ('Avalon' a a wingle work has no context other than for
a project), then you will regret the thousands of possibilities.
Imagine an abstract class that implements Avalon-Framework interfaces.
It is extended into a final Maillet that additionally implements
pertinent mailet APIs - e.g. ForwardingMaillet. Imagine also that
abstract class being extended into say a n EOB-bean for some modicum of
shared functionality. Not for EOB? Wel then, how about for FtpLet. Not
convinced there is any shared functionality? Well how about shared
understandability. A coder for JAMES maillets can quickly arrive
writing FtpLets without earning complete new APIs.
> There are my 2 cents for the night, sparked by drinking too much
> Mountain Dew during the NBA game.
Not a fan of the Football world cup heh? Currently drawing a couple of
billion viewers?
- Paul
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
