You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Danny Angus <Da...@slc.co.uk> on 2005/05/13 11:18:53 UTC
Re: Fast-Fail first proposal
I understand why you are keen to work from use-cases.
But I still strongly favour an approach which will..
1/ modify the protocol handling architecture to provide the _generic_
ability to assemble command handlers
2/ develop specific deployments of handers to satisfy the use cases. (and
tests of course, before anyone else says it).
I am 100% sure that 1/ is possible and 75% sure that it is reasonably
straightforward.
The benefit of this approach is that it addresses the identified cases, but
doesn't constrain the solution to address *only* the identified cases,
additional cases can be identified and addressed incrementally (with much
lower impact, lower risk and a lower requirement for regression testing)
once 1/ has been carried out.
d.
|---------+---------------------------->
| | <ap...@bago.org>|
| | Sent by: "Stefano|
| | Bagnara" |
| | <io...@bago.org> |
| | |
| | |
| | 11/05/2005 21:10 |
| | Please respond to|
| | "James Developers|
| | List" |
| | |
|---------+---------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'James Developers List'" <se...@james.apache.org> |
| cc: |
| Subject: Fast-Fail first proposal |
>-------------------------------------------------------------------------------------------------------------------------------|
--------------------------
Here is the updated list of useful fast-fail scenarios. In the bottom you
will find my first proposal.
--------------------------
A. SMTP connection: james currently always reply "220 server ready", we
could fast-fail based on:
A1. remote address
A2. current james resources/status.
B. SMTP "MAIL FROM:": james currently only checks address syntax, we could
fast-fail based on:
B1. banned sender addresses
B2. previous smtp status (AUTH/STARTTLS).
C. SMTP "RCPT TO:": james currently checks local/remote domains to decide
wether to relay or not, but we could add:
C1. provide "user unknown" for unavailable local addresses C2. provide
"mailbox full"/disabled and similar task
C2. previous smtp status (AUTH/STARTTLS).
D. SMTP "DATA": james currently reply "250 Message received" for each
message under the maximum size handled:
D1. add antivirus/antispam and other content filters and provide dedicated
failure feedback.
------------------------------
Here is the specific discussion for each scenario:
-------------------------------
A. This could be a common handling for all TCP/IP protocol services: we
should add a way to attach "plugins" to the servers so that they can
dinamically switch their availability.
out-of-resources, anti-flood/dos, rbl filters, and other IP/connection
based filters.
A simple "boolean accept(InetAddress remote-ip)" or better a method that
is able to return a string message.
We could also add an identical callback for accepting the socket
connection so we are able to refuse via socket or via SMTP protocol.
The second one allow us to tell something to the client, and a more
advanced usage would be to add a wait() in the accept() implementation when
system resources are low (many servers accept the connection immediatly but
only reply "220 server ready" where they are really ready).
This filters will be applicable to POP3, IMAP, NNTP, SMTP and any other
similar protocol and are indipendent from the specific protocol.
B+C. Here perhaps we can find a common solution for the macroscenario: I'll
name it "route filters" as it will filter based on source email address
or/and destination email address/addresses.
What we need here is:
- the specified address: from or to email address (probably not RFC822
address to support sourceroute
- the command parameters: probably as a single String (mail from could
have an "ENVID" parameter, rcpt to could have "NOTIFY" and "ORCPT"
parameters)
- the smtp conversation status: remote IP, remote PORT, time elapsed,
previous AUTH, TLS. Probably the best thing is to put everything as a
"Properties" as "smtp session information"
- the newly created Mail: I think that the MAIL FROM should create the
empty email and start filling-in data, so that at every RCPT TO call we
will
know not only the current recipient but also all the previosly used
recipients (we can limit the number of recipient per mail doing so)
Another possibility could be to have the MailImpl be created from the
call to this handler like a factory instead of providing the empty MailImpl
from the smtphandler.
probably the code that we will run in this handler will know wether a
recipient will be local or remote and will know the final name of a
recipient (after the virtusertable) before being able to reply, so I think
we should find a way to reuse this information when we will be in the
spooler: probably we can directly fill the MailImpl with the
expanded/aliased recipients and remove the corresponding mailets from the
spooling (I see problems here, but I'll tell them later ;-) ).
D. I think that SMTP "DATA" fastfail should be (IMO) handled in a fully
different way: we need something more integrated with the spoolmanager and
the DSNhandling.
I think we should add this support after a good refactoring
of the
delivery status tracking (I'm working on this, I will post my full proposal
soon).
--------------------------
Here is my current goal:
--------------------------
It would be great if we could agree on this general scenarios approach and
agree on the proposed solutions for A and D so we can start an in depth
analysis of the B and C handling.
If we agree on a partial solution I will take care to add a better
formatted
thing to the wiki as a reference. I think I will not commit to the
fast-fail
stuff soon because I have higher priorities: delivery status tracking,
spooler optimization, remote delivery optimization.
So I think I only will write code for the "D" point and only after my
coming-soon delivery status tracking proposal will be accepted and
committed.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
***************************************************************************
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by ap...@bago.org.
> > Btw,
> > this topic is mine ;-) and the proposal is for a problem at
> an higher level.
>
> Huh? "mine"? Don't go there, it isn't funny and won't win you
> any friends.
Hey Danny, please note the emoticons ;-)
Btw I don't think that friendship is an evaluation measure for proposals ;-)
> I am trying to help you to address your higher level problem
> by proposing an architecture within which you can modify
> James to resolve your use-cases.
Sorry, I think this "versus" discussion is pointless.
The MAIN difference I see is that I state my proposal goal and target is
different from your while you are trying to convince me that we should
choose the better between the two proposal.
I like your proposal and I hope you'll implement it because once committed
implementing my layer on top of your protocol handling layer will be easier.
I will resubmit my proposal again later.
As I said in my proposal footnotes I don't have time to work on fast-fail
right now: I'm working on DSN and RemoteDelivery optimisations. I tried to
discuss with dev mailing list members about my DSN changes with no
feedback, so I'm implementing the thing I need and I will submit directly
the patch. You will decide wether to accept the patch or not.
> > Again, I don't see problems with the 2 proposal, they are not
> > alternative
> > solutions: mine fast-fail extension behaviour will be built
> over your "api".
>
> I agree. I am not against your ideas, I'm just trying to put
> them in context.
I'm sorry if I repeat myself but I think our ideas are in different context:
there no needs to mix them.
I think that my is a "Fast-fail proposal" and your is a "Extensible protocol
handler proposal" but I don't want to choose the name for you so please
choose 2 names for the 2 layers and I will use them.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by Danny Angus <da...@gmail.com>.
On 13/05/05, apache@bago.org <ap...@bago.org> wrote:
> > > I think it is not a good idea to design an API
> > specification to solve
> > > problems you are not able to identify.
> > > You should design APIs for problems you are able to identify.
> >
> > That is true to a point. But an API can provide a simple way
> > to implement solutions for a class of problem.
> > You first identify the class of problem, then build a
> > framework for the general pattern of the solution, then
> > implement specific solutions for specific requirements.
>
> Ok, my use-cases identify a class of problem.
Yes and no, your use cases identify a number of cases from which we
can identify a class.
> Your pattern is a good thing to modularize the SMTP extension support.
> So that the DSN support can be isolated from the AUTH support that can be
> isolated from the STARTTLS support: IIRC Mike already developed such a
> system. You want to call it with an API name? Ok, no problem...
>
> Btw,
> this topic is mine ;-) and the proposal is for a problem at an higher level.
Huh? "mine"? Don't go there, it isn't funny and won't win you any friends.
I am trying to help you to address your higher level problem by proposing
an architecture within which you can modify James to resolve your use-cases.
I would oppose any attempt to modify James SMTP protocol which involved more
hard-coding of behaviour.
I am interested in maintaining James' ability to evolve to cope with
changing requirements and changing standards.
To that end I am proposing that your SMTP rules be implemented in a
way that allows them to have only one responsibility.
> > > Ok, I think your API proposal should not belong to the fast-fail
> > > domain: the topic of this thread is Fast-fail proposal.
> >
> > Which is what I'm proposing. An Architecture for the
> > implementation of fast-fail rules in James.
>
> You are proposing a protocol handling framework.
Yes I am. As part of this I am proposing an extension framework for
implementing fast fail rules.
> Your target is a developer
> with very good SMTP protocol knowledge that will use your api to develope
> NotYetDeveloped smtp estensions,
And rules for failure during the handling of protocol commands.
> my target is the advanced james
> user/developer that currently already easily create its own business mailet
> and that want to add fast-fail on smtp connection accepting and fast-fail
> per recipient.
This is not ruled out by my proposal.
> My target does not know how SMTP works, just want to create a
> class with a "acceptReciepient(Recipient)" method and return false for the
> unexistant recipients.
Which is also not ruled out by the proposal.
>
> This is totally different.
No it isn't, you are just taking a much narrower view than I am.
I am trying to open your eyes to the bigger picture.
>
> We should not mix the two thing in this topic.
We cannot help but mix them.
You propose making handlers for fast-fail. I am telling you how
I think they should be incorporated into James.
>
> > Mike said:
> >
> > "in spite of the fact that I brought up a similar idea to
> > Noel's on the list a while ago, I've changed my stance and
> > have to agree with Danny.
> >
> > I like Danny's comments because they resonate really well
> > with the work I've been doing with MINA. As I've thought
> > about this problem, it seams like a much better design to
> > modularize the SMTP handler to facilitate fast fails."
>
> Sure, Mike is a protocol developer: the target of your proposal. Mike is
> developing a full protocol handling, not a fast-fail mechanism.
You are proposing makgin chnages to James SMTP protocol hander.
I am showing you how to do this. You cannot talk about fast-fail without
talking about protocols.
>
> Remember: the target of my proposal does not know how SMTP works and should
> not have to read the SMTP rfc to do fast-fail. I don't want to use SMTP
> 3digit status code in java classes using the api I am proposing.
Thats OK, you can encapsulate this, use constants, expose them in the API,
document them.
Your "users" will want, at least, to be able to say whether a failure
is temporary or
permanent.
>
> Again, I don't see problems with the 2 proposal, they are not alternative
> solutions: mine fast-fail extension behaviour will be built over your "api".
I agree. I am not against your ideas, I'm just trying to put them in context.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by Mike Heath <mh...@avaloninc.com>.
<snip>
> > I think the API you are suggesting (or better the pattern) is good but I
> > also think that Mike already got working code with a similar pattern: we
> > should wait for his code commit/proposal.
>
> Mike said:
>
> "in spite of the fact that I brought up a similar idea to Noel's on the
> list a while ago, I've changed my stance and have to agree with Danny.
>
> I like Danny's comments because they resonate really well with the
> work I've been doing with MINA. As I've thought about this problem, it
> seams like a much better design to modularize the SMTP handler to
> facilitate fast fails."
I don't really have my own API per se so if you're waiting for me to
submit a proposal, you're going to be waiting a long time. As far as
committed code, instructions for checking my code out are available
here: http://sourceforge.net/cvs/?group_id=115603 The module name is
"mina_smtp".
My code relies heavily on MINA. MINA already has support for doing
protocol interceptors (which is what my STARTTLS implementation uses
when TLS is required.) Unless James is ready to move to MINA, my code
will only serve as a reference.
Going back, again, to Danny's proposal:
"----
ProtocolHandler - parses commands per protocol spec.
CommandHandler - matches command(s) and responds to the protocol
handler with a response code & message.
CommandRule - called by command handler to validate command,
responds with a response code & message
----"
The reason that I pointed out that I like this is because Danny's
ProtocolHandler maps to my ProtocolDecoder, Danny's CommandHandler
matches up to my ProtocolHandler/Command design and the idea of
CommandRules would fit in really well with what I'm doing.
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by ap...@bago.org.
> > I think it is not a good idea to design an API
> specification to solve
> > problems you are not able to identify.
> > You should design APIs for problems you are able to identify.
>
> That is true to a point. But an API can provide a simple way
> to implement solutions for a class of problem.
> You first identify the class of problem, then build a
> framework for the general pattern of the solution, then
> implement specific solutions for specific requirements.
Ok, my use-cases identify a class of problem.
Your pattern is a good thing to modularize the SMTP extension support.
So that the DSN support can be isolated from the AUTH support that can be
isolated from the STARTTLS support: IIRC Mike already developed such a
system. You want to call it with an API name? Ok, no problem...
Btw,
this topic is mine ;-) and the proposal is for a problem at an higher level.
> > Ok, I think your API proposal should not belong to the fast-fail
> > domain: the topic of this thread is Fast-fail proposal.
>
> Which is what I'm proposing. An Architecture for the
> implementation of fast-fail rules in James.
You are proposing a protocol handling framework. Your target is a developer
with very good SMTP protocol knowledge that will use your api to develope
NotYetDeveloped smtp estensions, my target is the advanced james
user/developer that currently already easily create its own business mailet
and that want to add fast-fail on smtp connection accepting and fast-fail
per recipient. My target does not know how SMTP works, just want to create a
class with a "acceptReciepient(Recipient)" method and return false for the
unexistant recipients.
This is totally different.
We should not mix the two thing in this topic.
> Mike said:
>
> "in spite of the fact that I brought up a similar idea to
> Noel's on the list a while ago, I've changed my stance and
> have to agree with Danny.
>
> I like Danny's comments because they resonate really well
> with the work I've been doing with MINA. As I've thought
> about this problem, it seams like a much better design to
> modularize the SMTP handler to facilitate fast fails."
Sure, Mike is a protocol developer: the target of your proposal. Mike is
developing a full protocol handling, not a fast-fail mechanism.
Remember: the target of my proposal does not know how SMTP works and should
not have to read the SMTP rfc to do fast-fail. I don't want to use SMTP
3digit status code in java classes using the api I am proposing.
Again, I don't see problems with the 2 proposal, they are not alternative
solutions: mine fast-fail extension behaviour will be built over your "api".
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by Danny Angus <da...@gmail.com>.
On 13/05/05, apache@bago.org <ap...@bago.org> wrote:
> I think it is not a good idea to design an API specification to solve
> problems you are not able to identify.
> You should design APIs for problems you are able to identify.
That is true to a point. But an API can provide a simple way to implement
solutions for a class of problem.
You first identify the class of problem, then build a framework for
the general pattern of the solution, then implement specific solutions
for specific requirements.
> IMHO this is a good architecture to be used to have a better designed
> protocol handler but we don't need an API: we just need to implement this
> pattern in our protocol handlers.
Without an API we limit ourselves to the issues currently under discussion.
>
> We were discussing about Fast-fail handling: IMHO fast-fail handling API is
> at an higher level. The james mailet-fast-fail API implementation could be
> based on a low level implementation of your command/rule pattern.
_NOT_ "mailet-fast-fail" mailets aren't competent to perform fast fail.
But, yes, thats what I'm trying to tell you, you could reuse matchers in
rules if that makes any sense.
Build the API, then implement the fast-fail rules which you want to use.
> > It is much more likely that James' users will wish to modify
> > James' behaviour than they will want to port James
> > functionality to other servers.
> > After all that is what _we_ are discussing. Isn't it?
>
> No. Not me.
Isn't it? This is the James developers list and you're talking about adding
fast-fail to James. protocol handlers aren't part of the mailet API
they're specific to James.
> Ok, I think your API proposal should not belong to the fast-fail domain: the
> topic of this thread is Fast-fail proposal.
Which is what I'm proposing. An Architecture for the implementation of
fast-fail rules in James.
> I think the API you are suggesting (or better the pattern) is good but I
> also think that Mike already got working code with a similar pattern: we
> should wait for his code commit/proposal.
Mike said:
"in spite of the fact that I brought up a similar idea to Noel's on the
list a while ago, I've changed my stance and have to agree with Danny.
I like Danny's comments because they resonate really well with the
work I've been doing with MINA. As I've thought about this problem, it
seams like a much better design to modularize the SMTP handler to
facilitate fast fails."
> Please give me at lease 1 fast-fail example not included in the use-case
> described.
I don't think you understand my point.
I don't know what other cases there may be, and neither do you. I could
either a) speculate, or b) provide an extension point which can be used
to implement new use-cases when they are identified.
I choose b)
This is one of the design principles behind the mailet api, and james
itself. Anyone can develop alternative implementations for a large
range of James parts.
> Again: I like your rule pattern, but I think this topic is not the right
> place for that.
The rules are rules for fast fail. This is exactly the place.
I've been thinking about this for a long time now, but until now we
we're unconvinced about the need for adding fast fail to James. If the
requirement is now admissable I think we should do it the James way, by
exposing an extension point and then implementing extensions.
> Your proposal is a protocol handling api and not a fast-fail handling api.
Fast fail is, by definition, a protocol handling issue.
We consider fast fail to be the termination of the protocol session with
an error and a message before the message has been received. Tell me
how you can do this *without* involving protocol handling?
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by ap...@bago.org.
> > > 1/ *is* the API and 2/ is implementations used to satisfy the
> > > use-cases.
> >
> > I don't agree on this. Most users will need to implement
> custom code
> > on the real use-case (2/).
>
> Actually most users won't.
> Some users may want to.
> Some users may want to implement use-cases which you haven't
> identified Some users may want to implement use-cases which
> you *can't* identify
I think it is not a good idea to design an API specification to solve
problems you are not able to identify.
You should design APIs for problems you are able to identify.
> > The 1/ is only needed to better modularize the SMTP code
> and only used
> > internally by james. When our SMTPHandle will have support for all
> > standard extensions then who will need to use the 1/ API??
>
> If you refer back to my original proposal:
>
> "----
> ProtocolHandler - parses commands per protocol spec.
> CommandHandler - matches command(s) and responds to the protocol
> handler with a response code & message.
> CommandRule - called by command handler to validate command,
> responds with a response code & message
> ----"
>
> You will see that I propose to implement THREE levels of
> entry into the protocol handling.
>
> a) implement a new protocol
> b) implement a new command
> c) implement a new rule to be applied to a command
>
> Anyone wishing to do *any* of these three things will be able
> to do so with no extra knowledge of James internals.
>
> > API's goal is also for code reuse: filters implemented
> using the API
> > should be easily be portable to other SMTP servers.
>
> I am proposing an API for extending James.
IMHO this is a good architecture to be used to have a better designed
protocol handler but we don't need an API: we just need to implement this
pattern in our protocol handlers.
We were discussing about Fast-fail handling: IMHO fast-fail handling API is
at an higher level. The james mailet-fast-fail API implementation could be
based on a low level implementation of your command/rule pattern.
> It is much more likely that James' users will wish to modify
> James' behaviour than they will want to port James
> functionality to other servers.
> After all that is what _we_ are discussing. Isn't it?
No. Not me.
> If you want to introduce reuse external to James this would
> require an independant API specification. Which I am *not* proposing.
Ok, I think your API proposal should not belong to the fast-fail domain: the
topic of this thread is Fast-fail proposal.
I think the API you are suggesting (or better the pattern) is good but I
also think that Mike already got working code with a similar pattern: we
should wait for his code commit/proposal.
> > The 2/
> > is based on what REAL USERS will need to change in the smtp
> conversation.
>
> By which you really mean what *your* opinion of their needs is.
> My proposal allows you to do this, but also allows anyone else to do
> whatever they _really_ want.
Please give me at lease 1 fast-fail example not included in the use-case
described.
> >I think that the 2/ api will be easily used by the same target that
> > currently implement mailets based on the Mailet APIs while the
> > 1/ api would be a lower level useful only for james core developers.
>
> Actually I strongly believe that this is not in scope for the
> mailet API.
Ok, I can agree on this.
> > If you don't agree please report a pratical example of how
> you imagine the
> > 1/ APIs as I didn't get this.
>
> Ah. You should have said so.
Again: I like your rule pattern, but I think this topic is not the right
place for that.
Your proposal is a protocol handling api and not a fast-fail handling api.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by Danny Angus <da...@gmail.com>.
On 13/05/05, apache@bago.org <ap...@bago.org> wrote:
> > 1/ *is* the API and 2/ is implementations used to satisfy
> > the use-cases.
>
> I don't agree on this. Most users will need to implement custom code on the
> real use-case (2/).
Actually most users won't.
Some users may want to.
Some users may want to implement use-cases which you haven't identified
Some users may want to implement use-cases which you *can't* identify
> The 1/ is only needed to better modularize the SMTP code and only used
> internally by james. When our SMTPHandle will have support for all standard
> extensions then who will need to use the 1/ API??
If you refer back to my original proposal:
"----
ProtocolHandler - parses commands per protocol spec.
CommandHandler - matches command(s) and responds to the protocol
handler with a response code & message.
CommandRule - called by command handler to validate command,
responds with a response code & message
----"
You will see that I propose to implement THREE levels of entry into
the protocol handling.
a) implement a new protocol
b) implement a new command
c) implement a new rule to be applied to a command
Anyone wishing to do *any* of these three things will be able to do
so with no extra knowledge of James internals.
> API's goal is also for code reuse: filters implemented using the API should
> be easily be portable to other SMTP servers.
I am proposing an API for extending James.
It is much more likely that James' users will wish to modify James' behaviour
than they will want to port James functionality to other servers.
After all that is what _we_ are discussing. Isn't it?
If you want to introduce reuse external to James this would require
an independant API specification. Which I am *not* proposing.
>If you declare the api at the
> 1/ layer then you contrain a specific protocol handling architecture.
Well, yes. But the mail protocols are all of the same
command->response form and the constraints are there to provide
consistent extension points to James.
> The 2/
> is based on what REAL USERS will need to change in the smtp conversation.
By which you really mean what *your* opinion of their needs is.
My proposal allows you to do this, but also allows anyone else to do
whatever they _really_ want.
>I think that the 2/ api will be easily used by the same target that
> currently implement mailets based on the Mailet APIs while the
> 1/ api would be a lower level useful only for james core developers.
Actually I strongly believe that this is not in scope for the mailet API.
> If you don't agree please report a pratical example of how you imagine the
> 1/ APIs as I didn't get this.
Ah. You should have said so.
-------------------------------- A protocol handler
public interface Protocol {
public abstract void handleConnection(Socket connection) throws IOException;
public abstract void setCommandMap(Map commands); //map of Commands
}
-------------------------------
---------------------------- A command
public interface Command{
public abstract String getCommandName();
public abstract Response handleCommand(String command, Map State);
public abstract void setRulesList(List rules); // List of Rules
}
-------------------------------
---------------------------- A rule
public interface Rule{
public abstract Response processArguments(String[] arguments, Map State);
}
-------------------------------
---------------------------- A response
public interface Response{
public abstract String getResponseCode();
public abstract String getExtendedCode();//possibly only in
extended SMTPResponse
public abstract String getMessage();
public abstract String getResponse();
}
-------------------------------
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by ap...@bago.org.
> > > 1/ modify the protocol handling architecture to provide the
> > > _generic_ ability to assemble command handlers
> > >
> > > 2/ develop specific deployments of handers to satisfy the
> use cases.
> > > (and tests of course, before anyone else says it).
>
> > I think that they are 2 needed layers: the goal is to
> support the 2/.
> > You can still use the 1/ as an intermediate layer to better
> evolve the
> > protocol handler. I think that from a configuration view we should
> > agree on the 2/ and expose an API then the 1/ is a more
> internal thing
> > (that probably doesn't need an API).
>
> 1/ *is* the API and 2/ is implementations used to satisfy
> the use-cases.
I don't agree on this. Most users will need to implement custom code on the
real use-case (2/).
The 1/ is only needed to better modularize the SMTP code and only used
internally by james. When our SMTPHandle will have support for all standard
extensions then who will need to use the 1/ API??
API's goal is also for code reuse: filters implemented using the API should
be easily be portable to other SMTP servers. If you declare the api at the
1/ layer then you contrain a specific protocol handling architecture. The 2/
is based on what REAL USERS will need to change in the smtp conversation. I
think that the 2/ api will be easily used by the same target that currently
implement mailets based on the Mailet APIs while the 1/ api would be a lower
level useful only for james core developers.
If you don't agree please report a pratical example of how you imagine the
1/ APIs as I didn't get this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by Danny Angus <da...@gmail.com>.
On 13/05/05, apache@bago.org <ap...@bago.org> wrote:
> > 1/ modify the protocol handling architecture to provide the
> > _generic_ ability to assemble command handlers
> >
> > 2/ develop specific deployments of handers to satisfy the use
> > cases. (and tests of course, before anyone else says it).
> I think that they are 2 needed layers: the goal is to support the 2/. You
> can still use the 1/ as an intermediate layer to better evolve the protocol
> handler. I think that from a configuration view we should agree on the 2/
> and expose an API then the 1/ is a more internal thing (that probably
> doesn't need an API).
1/ *is* the API and 2/ is implementations used to satisfy the use-cases.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Fast-Fail first proposal
Posted by ap...@bago.org.
> I understand why you are keen to work from use-cases.
> But I still strongly favour an approach which will..
>
> 1/ modify the protocol handling architecture to provide the
> _generic_ ability to assemble command handlers
>
> 2/ develop specific deployments of handers to satisfy the use
> cases. (and tests of course, before anyone else says it).
>
> I am 100% sure that 1/ is possible and 75% sure that it is
> reasonably straightforward.
>
> The benefit of this approach is that it addresses the
> identified cases, but doesn't constrain the solution to
> address *only* the identified cases, additional cases can be
> identified and addressed incrementally (with much lower
> impact, lower risk and a lower requirement for regression
> testing) once 1/ has been carried out.
I think that they are 2 needed layers: the goal is to support the 2/. You
can still use the 1/ as an intermediate layer to better evolve the protocol
handler. I think that from a configuration view we should agree on the 2/
and expose an API then the 1/ is a more internal thing (that probably
doesn't need an API).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org