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.
the matching language seems to suffer from XPath problems and risks to
become a very complex one. Let's leave this on the side for a moment...
we'll get back on it when we've finalized out ideas on the pipeline
creation.
> > 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 don't either (for now).
> I do think it might be useful to have one servlet call another servlet
> for complex routing.
If you allow this, then it is automatically possible to have a pluggable
pipelining architecture.
> 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).
I agree with this. Fede, this should make us all happy: we define one
way to do pipelines and you implement it as a Mailet, leaving the chance
for others to attach their own pipelines.
MailDispatching seems to solve our problems... but might create others.
> 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.
Totally +1 here. The Servlet API is a simple API but has an incredible
density and it takes years to test all the patterns involved and debug
them and allow me to say I know what I'm talking about having
partecipates in the creation of 2.1, 2.2 and now 2.3
> 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. :)
No, I disagree with your last sentence. True, this project doesn't have
the pool of users it deserves but, let me tell you, it's better to
design stuff when you don't have tons of people around.
If we have a bullet-proof architecture and solid ideas, then we can
stand tides of users later on with no problems, otherwise, the project
might sink due to tidal pressure.
Both Federico and I love to draw nice diagrams on the whiteboards... but
such abstract thinking pays off in the long run.
Both Avalon and James are our most risky bet, but, allow me, show the
best growth potention once they start working and people start using
them.
But mailet composition is a central thing, probably the core of the
whole system and the importance of a clean, solid and future-compatible
design should not be underestimated.
my 0.02 euros...
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
