> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
