james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [cycleclean] branch review and questions
Date Thu, 07 Jan 2010 14:13:51 GMT
On Thu, 2010-01-07 at 14:54 +0100, Stefano Bagnara wrote:
> 2010/1/7 Oleg Kalnichevski <olegk@apache.org>:
> >> It is NOT possible. Just look at the changelog. Every step is very
> >> well explained in the commit and in the relative JIRA issue.
> >>
> >
> > Isn't it great that now we have 'all or nothing' decision to make?
> 
> Just look at every revision one at a time. Then comment at every
> revision what you like and what you don't. I'll explain why that
> revision is needed for a following goal. Don't be impressed by the
> amount of changes I made in few days, you have revision numbers, it's
> not different than committing one revision today, one tomorrow, and so
> on, spending one month committing. The complexity of the changes are
> not different from what already happened in past releases.
> 
> BTW we are discussing of nothing. If you think there is something good
> and something bad in the branch let's discuss of specific code,
> otherwise if you think it doesn't worth your time reviewing or there
> is nothing good it doesn't make any sense to discuss about how big is
> the branch, what was the original goal for it and so on.
> 
> >> If you need explanations about some of that code just ask.
> >
> > Every time I raise a concern you basically say you know better, like
> > when I complained about really bizarre contract of
> > LineReaderInputStream#unread() method.
> 
> ?? I said I can explain WHY I did something. I know better what I did,
> I don't pretend to know better what you wrote ;-)
> When you complained for the bizarre contract I reacted by improving
> it. Your concerns have been very helpful.
> You didn't convince me that copying the unreaded buffer was a better
> option. You can veto it or you can collect more opinions against my
> solution if you really think it is not ok. You know, if I write code I
> write the code the way I think it must be written.
> 
> > I stated my opinion. Feel free to ignore it. If committing all these
> > changes is the price to be paid for your participation in further
> > development of mime4j, I guess it is the price worth paying. I just do
> > not think it is okay to have made lots of API changes all over the
> > project and leave us with a decision to choose all or nothing.
> 
> I never asked you for such a decision. I asked if people agreed that
> the current api is a mess. I think it is a mess. The only way to fix a
> mess is to make a lot of changes. The only way for me to introduce the
> improvements I need in my current project is to have the mess fixed,
> so I started coding to show what I mean as fix the mess. I always
> think the code is the interesting thing. I have my limits, and one of
> them is that I'm not able to work on a software that doesn't have a
> clear architecture. And having dependency cycles most time means I
> can't help improving things. I fixed dependency problems already in
> mime4j 0.4 but unfortunately 0.5 and 0.6 introduced a lot more of
> them, breaking the design contracts present in 0.4. Unfortunately I
> had no much time to review 0.5 and 0.6, otherwise I should have
> probably raised my concerns before this.
> 

Mime4j API is a mess but now we simply have a different mess, at least
in some areas of core packages

> Please, let's talk about revisions and code.
> 

(1) Please revise / redo BasicMimeTokenStream / MimeTokenStream split or
revert 895241. Consider making MimeTokenStream an interface as an
option.

(2) Please make sure  LineReaderInputStream#unread() does not impose a
particular mode of operation.

Cheers

Oleg


> If you agree that mime4j needs a refactoring, that the current API is
> a mess, that the DOM classes should not depend on parser classes, that
> the library entry points should be reduced to a small subset of
> classes and you are fine sacrificing backward compatibility for this
> then there is space for review, discuss and improve the branch until
> it is ok to merge, otherwise if we have different goals there is no
> way that this discussion about the branch will bring us anyway.
> 
> Please note that I'm really fine even if you prefer to follow the "no
> changes in mime4j" line. It's just I need to be agile on my current
> project and I need a mime parsing library with some features that is
> not in mime4j but it already is in cycleclean. I can keep working on
> the branch or I can work also outside this project if anyone think
> that the branch is disturbing. Zero personal issues from me. I'm in
> the James PMC and all I want is a good community and teamwork. There's
> no point in opensource without teamwork. This doesn't mean that I will
> agree on everything you say. It is good to have different ideas, so we
> have much more ideas together.
> 
> Stefano
> 



Mime
View raw message