> My take on the container is that we it to just be there, support our
code,
> be free of memory leaks and crashes, and otherwise stay out of our way.
Agreed. And i don't normally pay it much attention, but with people talking
about Merlin I wondered what your idea was.
> I agree, but would reverse the order. Having JNDI in the Mailet
environment
> will impact what we can expose, and how, which will impact discussion and
> consideration of what should be added to the Mailet API, itself.
Actually I spent this w/e reviewing the Mailet API, and apart from moving
the processor and repository interfaces and a couple of implementation
methods from James to Mailet. I don't think theres anything contentious in
my ambition, I'm not proposing archtectural changes and have carefully
considered everyone's input into our earlier discussions.
I want to start, though, by preparing a draft spec based on the current API
and changed to fix the glaring holes.
I don't think there's much reason for doing JNDI or API changes in any
particular order, save that I'd like to have a specification which
specifies the role and beaviour of JNDI first.
There's no reason why we can't cycle through two or three alpha versions of
the spec and implementation.
But I'll post my early work here for review before I commit anything.
> > Add support for archived application auto deployment, probably on the
> > basis of deploying "Processors" . Tighten classloader separation and
> > add JNDI local contexts for secure separation of processors.
>I think we should revisit processors and mailets again, as we started to
>discuss earlier in the year.
Yeah, OK, but.. first of all I think we got some clear opinion, and
secondly I'm not proposing any change of behaviour there, particularly not
anything which would obstruct changes we might consider on the lines of our
last discussion.
I merely want to make processors the basic element of auto-deployment, as
they seem to strike a nice balance between size and flexibility.
The only change I will propose is that LinearProcessor be allowed to not
terminate mail so that unhandled mail can fall back through.
Of course in line with my belief in the philosophy of least suprise I'd
make this a config option turned off by default.
The significant bit is that Peter Goldstein considered that:
"It is an essential part of the contract of the LinearProcessor that a
particular matcher/mailet combination be used to terminate the processor
chain"
I disagree, and believe that it is not part of the contract at all,
certainly it is not expressed anywhere except for the code.
Rather we need to specify exactly what the behaviour is here, and we can
specify anything, so why not specify the flexible option. It could simply
(and consistently with current practices) be implemented by a <passThrough>
option in ToRepository or a passThrough attribute in <processor> config.
> > $) Add flexible virtual hosting. Offering a choice at config time of
> > either IP based using bound IP's or name based using rich account
names.
> I think we already have this, or are very close.
Agreed. I don't think it'd be a big job, but it's been outstanding for
*so**long* I think it has to be on someone's worklist this time round.
> We might want to record our collective ideas on the wiki, where we
already
> have others: http://wiki.apache.org/james/JamesV3. Looks like we've
already
> done some, and have new ideas on others. Serge would probably suggest,
and
> he's right, that we start to use JIRA to layout our roadmap concretely.
Perhaps we should use a status file, which only the commiters can alter,
rather than the wiki which can be hacked around by strangers?
d.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not the intended recipient (or responsible for delivery of the message to
the intended recipient) please notify us immediately on 0141 306 2050 and delete the
message from your computer. You may not copy or forward it or use or disclose its
contents to any other person. As Internet communications are capable of data
corruption Student Loans Company Limited does not accept any responsibility for
changes made to this message after it was sent. For this reason it may be
inappropriate to rely on advice or opinions contained in an e-mail without obtaining
written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to
scan attachments (if any). Opinions and views expressed in this e-mail are those of
the sender and may not reflect the opinions and views of The Student Loans Company
Limited.
This footnote also confirms that this email message has been swept for the presence of
computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
