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