You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Claude Duguay <re...@verizon.net> on 2003/04/07 18:23:50 UTC
Design Observations
While I'm working on this, it occurs to me that a few observation about
the Mailet/Matcher might be useful to the designers and may help improve
usability.
1) The ability to configure parameters/arguments in the Matchers is not
idea. Since you can get a handle to the MailetContext from the Matcher,
it seems that a method that provides access to the getInitParameter
method would be useful. In configuring my Mailet, I have found the
process inconsistent. For example, if I need to have the matcher aware
of a directory, both the argument that follows the Matcher declaration
(after the '=' character) AND a Mailet parameter have to reflect the
same target directory. It would be easier to configure Matchers if the
same arguments were reacheable. If they are already, please let me know.
2) Access to a mail repository is not very effective and requires
convoluted code. My own application uses a separate directory, given
that it was primarily developed for illustration purposes. However, it
seem that storing messages in a Mailet should be done through the same
mechanism. When I looked at source code from existing mailets, I
concluded that too much code would be involved which was not part of the
API. I'd like to recommend that access to the repository from the
high-level abstraction (such that the underlying implementation is
transparent) should be part of the API.
3) Documentation needs work. 'Nuff said.
On the upside, I like the power available in James. If a mechanism was
developed to allow JAP (James Application Package?) files (JAR files
with a specified structure) to be dropped into a predictable directory,
without rebuilding the James.SAR file, I think you'd be on to something
that could be widely deployed. As it is, however, it's probably easier
and more efficient to process content through sendmail pipes. That being
said, I love Java and think it's much easier to work with as an
application language.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Design Observations
Posted by Claude Duguay <re...@verizon.net>.
Your message is not curt, merely to the point. I have largely completed
the pair of articles I wanted to write and could use at least a cursory
review by one of the principals of this project. I'm not sure who I
should ask.
That the packaging and deployment issues are complicated will be
addressed in the articles by a comment on the fact that the team is
aware of the issue and working on it. I did not touch on the repository
issue at all, so it requires no explanation. I do not have a full
understanding of the processing chain, however, and could use a
clarifying message or two if anyone's up to it. There is a root
processor and others, how do things branch and get processed, based on
the order in which they are declared?
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Monday, April 07, 2003 9:33 PM
To: James Users List
Subject: Re: Design Observations
Claude,
Thanks for your comments. I wouldn't normally send such a curt message,
but most people are pretty strapped for time these days. So quickly:
Claude Duguay wrote:
> 1) The ability to configure parameters/arguments in the Matchers is
> not ideal.
1. The way matchers are associated to mailets is a function of how the
linear processor is defined. Matchers are not meant to have a 1-to-1
relationship with mailets, and for James 3.0 there will be mail
attributes that allow matchers and mailets to communicate with each
other. Mail archives will have never-ending thoughts on this and Wiki
will have it briefly summarized.
> 2) Access to a mail repository is not very effective and requires >
convoluted code.
2. Yes, this has also been discussed extensively. The leaning is
towards using JavaMail for mail stores, possibly with a meta-layer to
that for the spool stores, and the spooling logic would layer on top of
this. Mail archives will have various threads on this.
> 3) Documentation needs work. 'Nuff said.
3. To use Volkwagen's tagline, "Volunteers wanted!"
> On the upside, I like the power available in James. If a mechanism
was > developed to allow JAP (James Application Package?) files (JAR
files > with a specified structure) to be dropped into a predictable
directory, > without rebuilding the James.SAR file, I think you'd be on
to something > that could be widely deployed. As it is, however, it's
probably easier > and more efficient to process content through
sendmail pipes. That being > said, I love Java and think it's much
easier to work with as an > application language.
And to your final point, Danny Angus had recently been trying to get
class loading working better for 3.0. I'm not sure what the state of
this is.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/ p.
1.301.656.5501 e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Design Observations
Posted by Danny Angus <da...@apache.org>.
> > 2) Access to a mail repository is not very effective and requires
> > convoluted code.
>
> 2. Yes, this has also been discussed extensively. The leaning is
> towards using JavaMail for mail stores, possibly with a meta-layer to
> that for the spool stores, and the spooling logic would layer on top of
> this. Mail archives will have various threads on this.
this is *much* simpler in Mailet v3,
getMailetContext.getMailRepository("name");
> And to your final point, Danny Angus had recently been trying to get
> class loading working better for 3.0. I'm not sure what the state of
> this is.
There is "drop in" installation for mailet jars and classes, but no seperation between James and Mailet classloaders yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Design Observations
Posted by Serge Knystautas <se...@lokitech.com>.
Claude,
Thanks for your comments. I wouldn't normally send such a curt message,
but most people are pretty strapped for time these days. So quickly:
Claude Duguay wrote:
> 1) The ability to configure parameters/arguments in the Matchers is
> not ideal.
1. The way matchers are associated to mailets is a function of how the
linear processor is defined. Matchers are not meant to have a 1-to-1
relationship with mailets, and for James 3.0 there will be mail
attributes that allow matchers and mailets to communicate with each
other. Mail archives will have never-ending thoughts on this and Wiki
will have it briefly summarized.
> 2) Access to a mail repository is not very effective and requires
> convoluted code.
2. Yes, this has also been discussed extensively. The leaning is
towards using JavaMail for mail stores, possibly with a meta-layer to
that for the spool stores, and the spooling logic would layer on top of
this. Mail archives will have various threads on this.
> 3) Documentation needs work. 'Nuff said.
3. To use Volkwagen's tagline, "Volunteers wanted!"
> On the upside, I like the power available in James. If a mechanism was
> developed to allow JAP (James Application Package?) files (JAR files
> with a specified structure) to be dropped into a predictable directory,
> without rebuilding the James.SAR file, I think you'd be on to something
> that could be widely deployed. As it is, however, it's probably easier
> and more efficient to process content through sendmail pipes. That being
> said, I love Java and think it's much easier to work with as an
> application language.
And to your final point, Danny Angus had recently been trying to get
class loading working better for 3.0. I'm not sure what the state of
this is.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Design Observations
Posted by Danny Angus <da...@apache.org>.
> 1) The ability to configure parameters/arguments in the Matchers is not
> idea. Since you can get a handle to the MailetContext from the Matcher,
> it seems that a method that provides access to the getInitParameter
> method would be useful. In configuring my Mailet, I have found the
> process inconsistent. For example, if I need to have the matcher aware
> of a directory, both the argument that follows the Matcher declaration
> (after the '=' character) AND a Mailet parameter have to reflect the
> same target directory. It would be easier to configure Matchers if the
> same arguments were reacheable. If they are already, please let me know.
We're still at the dicussion stage here, thanks for your input.
>I'd like to recommend that access to the repository from the
> high-level abstraction (such that the underlying implementation is
> transparent) should be part of the API.
It is already in place for v3.
> 3) Documentation needs work. 'Nuff said.
You're a writer Claude? If you want to contribute your experiences we'd be *extremely* happy to include them.
(You can go to town on the wiki if you dont fancy contributing directly, from which we can harvest words for the docs.. http://nagoya.apache.org/wiki/apachewiki.cgi?James)
> On the upside, I like the power available in James. If a mechanism was
> developed to allow JAP (James Application Package?) files (JAR files
> with a specified structure) to be dropped into a predictable directory,
> without rebuilding the James.SAR file, I think you'd be on to something
> that could be widely deployed.
This is 100% what the plan (http://nagoya.apache.org/wiki/apachewiki.cgi?James/Development) is, we are having to contend with very slim resources of developer time at the moment, coupled with concerns about maintaining compatibility between Mailet v2 and Mailet v3. Once we have addressed the classloader issue fully (Peter Goldstein has also contributed to this effort) we'll be in a position to move towards a simple deployment pattern.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org