On Thu, 2010-01-07 at 14:54 +0100, Stefano Bagnara wrote: > 2010/1/7 Oleg Kalnichevski <[email protected]>: > >> 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 >
