Stefano Bagnara wrote:
I believe this is something we already have.
We have to define the requirement for what we want to have different
in the next version before creating this draft, don't you think?
Not fully...no. Goals yes, I think we've mostly done.
Imho the concepts that are already there like the MailetContext and
the way we configure the mailets via attributes should not be removed.
I agree that we should separate the mailet project from james server
and have its own repository folder, its own build script, its own
website section, its own wiki section.
Excellent!
I guess that January 1st is too much optimistic as a goal as we just
started talking about the high-level goals, and it seems to me that
we'll need time to find a common solution.
That said, I think that the way to go is
1) find an agreement (possibly shared) on the goal of the api
2) start discussin the different architectural solutions to achieve
the goal
3) try to implement the "alpha" apis in our products to find out
possible problems and refine the APIs.
4) publish the official version of the api as a standalone product.
And that is a very common way of doing things in many spec committees.
However, I think we have different learning styles involved here and an
opportunity to work with them more efficiently. I tend to understand
via code (and tend to scan emails) and I think others are the same (but
not all). So we identified some pieces off the bat that we mostly agree
on. So the idea is let's implement them in the most trivial way (like a
unit testy thing) and start specing them out! I strongly suspect this
will help keep the discussion heat rather low and scope the conversation
to the task at hand. Discussions should continue in parallel and in
parallel I certainly plan to be implementing them on our server (many
details of which you probably don't care about) and I imagine you'll be
doing the same (I'm just not interested in all of the nitty gritty
details of that either).
Stefano
Andrew C. Oliver wrote:
Ideally, by ~January 1, I'd like to see a draft proposal of the
Mailet interfaces
Injection configuration
"core" apis (like Mail.java or whatever)
With a "startup" class similar to:
Mailet2Draft.java
public static void main(String args[]) {
String mailetconfig = args[0]; //a cheesy prop or xml file to
config this
String mailstream = arg[1]; // a sample input stream to process
Mailet2Draft m2d = m2d.readConfig(mailetconfig);
BufferedInputStream bis = new BufferedInputStream(new
FileInputStream(mailstream));
m2d.process(bis);
}
Which can be built simply (like by a build.xml or build.sh) w/o any
JAMES stuff.
And a wiki page with a draft specification describing the contracts.
I am willing to contribute to the effort.
-Andy
