----- Original Message -----
From: "Roberto Lo Giacco" <[EMAIL PROTECTED]>
To: "Java Apache Mail Server" <[EMAIL PROTECTED]>
Sent: Wednesday, August 30, 2000 12:25 PM
Subject: Re: New mailet API proposed
> > Please let me know what you think of the new API so far...
> > http://www.lokitech.com/~sergek/mailetdocs/ I'll continue to Javadoc
> > more stuff as I go and might need to add a few methods as I finish
> > porting all the mailets... not all the classes/interfaces have a top
> > level descriptive comment, but I think just about every method in every
> > class/implementation has one.
>
> 1. Mailet.service() method should throws MailetException, maybe even
> IOException, rather than the generic Exception.
Yes, was thinking about that last night. Seems like a good idea.
> 2. Mailet.init() metod should throws MailetException to handle
configuration
> errors.
Again seems like a good idea.
> 3. Introduction of an Address class which ensures a mail address is well
> formed encapsulating such functionality and overloading every method which
> uses a String as for mail address to be used with an Address type:
overloaded
> methods wich uses String should call the correspondent method with a new
> Address instance created with the String contents.
Originally we supported these, but for convenience we had stopped. I think
you're probably correct in leverage the existing Address class strengths,
but I will have to check how much this complicates extra code.
> 4. Rename the MailetContext.getMXRecords() method into something which
doesn't
> contain a DNS specific acronym: getMailServers() or getMailPath() or
> getMailDispatcher() will be better.
Ok, I'll probably name it getMailServers unless something else comes along
that's better.
> 5. Suppress the MailetUtils class which actual functionalities could be
> obtained using the Address class which will have static methods to parse a
> String returning the host part or the user part.
Yes, see 3 above.
> 6. Add to the GenericMailet class the getMailetName(), getInitParameter()
and
> getInitParameterNames() methods only for convenience.
Good catch.
> On Matcher I haven't understood why you defines a totally new interface: I
was
> thinking matching rules was something strictly binded with Mailet exactly
as
> request and response are binded to Servlet. IMO rarely I'll have a Mailet
> without a matcher so I think matching rules should be considered more
Mailet
> paramethers than classes.
This is a little harder to explain. The quick answer is because servlet's
have URL matching, and mailets don't have anything quite so obvious, or
rather, they need more flexibility. When a servlet container receives a
request, it can look at the URI and determine which servlet to send this to.
Mailets need more flexibility... a mailet might fire on every incoming
message, might only fire on messages sent from this network, only on this
recipient, etc... Also, servlets are a single response, while mailets are a
series of filters. Finally (and most complicated), a mailet could have
multiple recipients, which means some mailets would only fire on a subset of
the recipients. The matcher returns the subset of the recipients that the
associated mailet should service, and the mailet container (mail server)
splits the message into 2 messages and splits the recipient list. Each
message then continues through the mailet container separately as the mailet
might have changed the subject or the body or what have you.
We realized that there are probably half a dozen to a dozen standard
"matches" that you'll want to check before a mailet executes, and with that
we built the separate interface so you don't have to rewrite this in every
mailet. Imagine if every servlet had to check the requestURI to see whether
it should execute or not... would just be a lot of extra code.
> An approach I wish to suggest is to define matching rules inside the
Mailet
> interface (still able to extend matching rules) and binding their matching
> values as configuration parameters: when the GenericMailet init() is
called
> (still able to override matchers behaviour) it reads such parameters and
> initializes corresponding inner classes (I prefer inner because they have
no
> more reason to be usable outside the GenericMailet class) which match
method
> will be then available at service() time.
I'm not sure I completely understand this approach. Perhaps the above
explanation will help explain why we did it this way. With our approach,
you could handle much of the logic just in the conf file, which we viewed as
desirable... with half a dozen or so matchers and a dozen or so mailets,
this seemed to accomplish 75% of what people would want the mail server for.
For the last 25%, they could write their own matchers or mailets.
> Am I going in the wrong design pattern? If not and you need help I can
> personally make the canges if you send me the source of the new mailet
API.
I'll make the changes you suggested tonight as well as anything else I've
changed and repost the javadocs.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
