Noel J. Bergman wrote:
I see all of the work here, and Norman explained on Skype what he and
Stefano are doing, but this is not the way that we develop code. Please
correct me if I am wrong, but I do not see a single message, much less a
discussion, of the ideas, plans, etc., for this code.
Norman opened the handlerapi-experiment branch to try to revamp the
architecture of this "fastfail" stuff that already changed so much time
in the last months. Suddenly he asked me to help him with the push-based
demo code you wrote, so I tried to understand it, compared it to MINA,
and created something usable that I attached to JIRA:
http://issues.apache.org/jira/browse/JAMES-750
You can see some explanation in the issue description/comments.
Norman liked it and decided to open an handlerapi-experiment branch to
find out what else could be done and invited me to work there (also in
the JIRA comments).
There is not a proposal yet, because we are experimenting, and we'll
make a proposal once we'll be happy with something in that branch.
I personally found this branch very interesting because I have had the
opportunity to try some of the ideas I had in past, and I found that a
lot of them was good, but a lot of them was simply not applicable to the
concrete case.
We are working almost indipendently on that branch: each one take the
last code and add his own ideas/fixes/revert.
Of course if you have ideas they are welcome, but don't take that branch
code too seriously: they are experiments, imho we are still far (far = I
guess 20-40 man-hours of work) from something mergeable to trunk.
I currently like the new branch much more than the solution we have in
trunk and in the other handlerapi branches, but I want to take more time
reviewing the current "plugins" and, for example, I want to make sure
the new architecture can support my "DSN support" needs, before creating
a concrete proposal: I'm not yet satisfied enough to consider this ready
for worthwhile discussion. I know the PMC members have not much time, so
I prefer to avoid abusing their time with not critical discussions.
Much code has been written in hurry, with the simple goal to create a
strawman implementation. Details and a much better review can be done
after a proposal will be done IF we'll have agreement on the solution.
As I understand it, the gist of it was to take the Handler API and merge in
the work that I had done on push model I/O. Apparently, they then decided
to adopt some of the ideas from QPSMTP for plugins. All fine and dandy, but
again, if this was not done in a collaborative manner involving the
community, I don't see it. If it is there, I apologize for missing it.
Please point it out so that I can respond to those discussions. Else I will
start new threads for people to discuss the code.
On 28/10/2006 Danny said about the "sandbox/mailet-refactorings" branch:
------
> Compromise my ass, this is my sandbox fork Muahahahh ! ;-)
> What I mean is, this project doesn't have to achieve consensus itself,
> as long as it helps us to understand what the underlying problems are
> which have resulted in no agreement for such a long time.
> After this fork is all done we won't have Mailet v3, we'll have a plan
> for Mailet v3, which might well include decisions which still need to
> be bottomed out.
>
> d.
------
I replied to him
-----
> ++1 You know I'm a fan of "code based proposals".
> I just put a "beware the DI fanatics" and a "beware the JNDI haters"
> signs near your sandbox :-P
-----
I worked on that sandbox with that spirit. Work toward something
concrete to propose. If you have "signs" to put near this sandbox I will
be really happy to read them.
I preferred to avoid discussing the technical thing too much on the list
because I had no idea of what I would have done there. It is really a
sandbox to try different approaches to an user-oriented extensible api
for fastfail. If I will have time I would like to try to port the
current sandbox pattern to all of our services (imap/pop3/remote
manager) so that we can collect more use-cases for the api. I didn't
work on the handlerapis since 2.3.0 so I didn't have much knowledge of
the current trunk architecture and the current handlerapi-v2 branch
architecture, so I took the handlerapi-experiment as an opportunity to
study and put my hands in the sandbox before starting proposing
something about an issue that I didn't know well.
Furthermore I preferred to not introduce more discussions on the list
while we are trying to solve the 2.3.1, next-minor, next-major roadmaps
that I consider much more important than an experimental branch.
Of course we'll make a concrete proposal once we'll agree we have
something that worth being reviewed. This also means that I wouldn't
mind if anyone will want to veto a merge of this stuff once we propose
it: I won't consider this as time lost, because I'll have a better
understanding of the current smtpserver and maybe also something usable
on my local branch if I will not be satisfied with what we'll agreed to
include in 2.4/2.5 or 3.0.
I hope this answer most of your questions, if you have any other
curiosity or any hint, you're welcome.
Personally, I have some issues with the code, but nothing that can't be
corrected.
--- Noel
I'm happy for that and maybe the issue you have are the same I want to
resolve in order to feel fine with the code.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
