Serge Knystautas wrote:
>
> Federico Barbieri wrote:
> > <match id="CheckHeader=sender:[EMAIL PROTECTED]"/>
> >
> > where CheckHeader is the class name instead of
> >
> > <match id="checkHeader"/>
> > ....
> > <match id="checkHeader" class="CheckHeader">
> > <name>sender</name>
> > <value>[EMAIL PROTECTED]</value>
> > </match>
> >
> > I just think the first one is less verbose and it's enought to cover all
> > needs... but I'm not sure about it... maybe a AntiSpam cmatch needs much
> > more configuration than a single line.
>
> I prefer the later (more verbose) version because it's more flexible and
> easier to validate with XML (the XML parser can tell me the line and
> column I messed up my conf file). I would even say it's more readable.
>
Fine for me.
So can we define once forever a definition sintax for both mailet and
match?
Something like
<mailets>
<mailet id="[name]" class="[full package class name]">
...
</mailet>
<mailet ....>
</mailet>
</mailets>
<matches>
<match id="[name]" class="[full package class name]">
...
</match>
<match ...>
</match>
</matches>
<processorpipe>
[here goes brainstorm]
</processorpipe>
Is it ok?
> > Basically from the spool you get one mail and you call someone to handle
> > it. Just one mailet can do the job and from James point of view it is
> > irrelevant how it is handled. So I can write a mailet that calls other
> > mailet depending on its configuration. This "root mailet" is what I
> > called processing pipe.
> > So I can plug a root mailet that reads tree like configurations and
> > makes specified mailets work this way or I can plug a different root
> > mailet that reads linear confs and makes mailets work that way. We ca
> > write two or three differen root mailet to cover every differen need,
> > from the isp with 10000 users with no specific need to the ecommerce
> > mail application provider with fewer users but a bunch of intricated
> > mailet structure.
> >
> > In other way i think we should take the processing pipe logic out of
> > JamesSpoolManager.java and make it pluggable.
> >
> > If you look at ProcessingPipe.java and Pipe.java (horrible names but I
> > couln't find any beter) you'll see that those are mailet handling other
> > mailet based on their configurations.
>
> I really don't like the idea of letting people completely swap out
> conf/routing. I really don't see people having that massively complex
> mail apps at 1.0 of james that we need to do something like that.
>
> I do think it might be useful to have one servlet call another servlet
> for complex routing. I don't like directly referencing one servlet from
> another, and I really don't like one servlet instantiating other
> servlets. I think when we go to this, we should have a MailDispatcher
> to handle routing issues, but I'm not sure how you have one servlet
> reference another one since we don't have convenient URLs. I think the
> closest thing we have is the servlet name (as specified in the conf
> file), and maybe we should just go with that for now, e.g.,
> getMailDispatcher(String serverConfName).
>
> Not to draw parallels to Http Servlets, but it's been 2 years and their
> internal routing between servlets still isn't perfect... I don't think
> we need to solve all of these issues before we release 1.0. Let's just
> try to solve some of the basics by 1.0: listserv, virus scanning
> attachments, antispam, autoresponders (vacation, joke-of-the-day,
> etc...), file retrieval, and delivery (remote SMTP server, mailbox,
> NNTP, RDBMS, whatever...). If we can do all these well, there are
> probably other features we could add to james that are more valuable
> than an internal routing system. <sigh> I'm just a little down
> because you two are obviously have time and interest to work on james,
> and the code still needs a lot of work, and while the configuration
> system we're almost reached looks really great, an advanced and complex
> routing discussion just seems like low priority for a group of guys with
> only a few users. :)
>
I get your point and I agree. It's just my usual bad attitude to keep
projects under infinite "under construction"... :-) I just can't stop
thinking of new features.
Ok so let's say that all these discussions refere to a 2.0.
What about letting the pipe as it is and just add some mailet as you
suggest?
I'll take care of order a bit sources and you can add mailet.
i think letting code condense into something more solid can give all of
us a better view of the problem. And I'm sure no path are blocked for
future releases.
Ok?
Fede
P.S. Just one thing need to be absolutly unchageable from now... it's
the mailet interface.
I agree with you 'bout not returning anything from the service but I
don't think a boolean is a good point. A mailet MUST take care of
handling the mail and if this do not happend it's an error and an
exception should be thrown, not a boolean "false". So my purpose if
public void service(Mail mail);
Comments?
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
