james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Experimental Handler Branch
Date Tue, 02 Jan 2007 00:52:23 GMT
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:
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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message