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: [mime4j] what else need to be done (Was: Benchmark of 0.3 vs 0.4)
Date Wed, 06 Aug 2008 09:51:04 GMT
Niklas Therning ha scritto:
> Stefano Bagnara wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Aug 5, 2008 at 6:16 PM, Bernd Fondermann
>>> <bernd.fondermann@googlemail.com> wrote:
>>>> On Tue, Aug 5, 2008 at 18:52, Stefano Bagnara <apache@bago.org> wrote:
>>>
>>> <snip>
>>>
>>>>> IMHO this one (use the new structure but move some class from 
>>>>> parser to
>>>>> main) is the worst of the 5 analyzed, but I won't veto it, so if 
>>>>> this is
>>>>> what the majority wants, I'm fine with it.
>>>> I don't think that Apache is about majority decisions in the first
>>>> place. Majority decisions (votes) are often not including minority
>>>> opinions, while finding consensus is about taking every opinion into
>>>> acount (known as 'compromising'). If that doesn't work, votes come
>>>> into play. (Disclaimer: The readers notion about 'The Apache Way' may
>>>> vary.)
>>>
>>> i think it's important to let people know about changes like this and
>>> assemble some kind of rough consensus before embarking. i think
>>> there's now a consensus that these changes are broadly an improvement
>>> but that more refinements are possible. let's just apply the proposal
>>> and then start working on the improvements.
>>
>> MIME4J-51 proposal has already been applied, unfortunately what I 
>> thought was consensus a week ago now seems something invented by me ;-)
>>
>> My questions to Niklas and Bernd are really to understand if 
>> "refinements" is something that can be done on the refactored tree or 
>> if the consensus is now too far from that and we should better revert 
>> it and start from that.
>>
>> I'm scared that people think I'm pushing my proposal or pushing my 
>> cycle dependencies issues when I just want to see something done.
>>
>> I hope Niklas will update us soon, without fears or bad feelings wrt 
>> this thread, and I also hope that someone else with better 
>> communications skills can show what's wrong in the way I try to build 
>> consensus.
> 
> Hi,
> 
> I certainly understand the merits of trying to reduce cyclic package 
> dependencies, especially for the developers developing the software. My 
> only concern is that zero cyclic dependencies in a library such as 
> Mime4j doesn't necessarily mean that it will be easier to use for the 
> end user.

I think mathematical methods are the only pragmatic method to classify 
classes in packages. Otherwise we speak about personal preferences, 
that's why I'm so used to dependency analysis.
IMHO a dependency graph and a correct package hierarchy tells much more 
than any documentation.
I understand this is a matter of personal feeling/style and I don't want 
to convince anyone, nor to be convinced by anyone.

> I definitely think that most of the refactorings you've made are great. 
> My suggestion was only to move the four classes/interfaces I mentioned 
> to the root package. That's all. I've played around with JDepend and if 
> I understand correctly this change results in a single cycle (mime4j <-> 
> parser).

I tried the change and I find 6 cycles, more about this at the end of 
this message.

In my experience either you care of cycles and remove all of them or you 
don't care at all of them. There is no such thing as "reduce the 
cycles". Either the package dependency graph is a tree or it is not a 
tree, there is nothing in the middle.

before-MIME4J-51 the main package contained core classes like 
BodyDescriptor and MimeException used by almost all the code and every 
package and at the same time it contain parser classes that use code 
from every package. If you put them in the same package you introduce a 
lot of cycles, there is no way around or compromise for this.

I understand that some practice is frustrating for people not embracing 
it and that's why I took the proposal way and that's why I would happily 
accept to revert the change (if this will be the consensus) and I won't 
try to convince anyone of my opinions.

> My gut feeling is that this would make it easier for the end 
> user. However, as an active committer I'm not the typical end user 
> myself so my gut feeling could be wrong. I can definitely live with what 
> is in trunk right now. To me it is more important that we release a new 
> version soon. Also, at this stage of the project I think we can afford 
> to (and probably we will) change our minds about the package hierarchy a 
> couple of times more as the code evolves.

I agree on the release: let's not link this issue to the release or will 
make a fast/bad decision for an unrelated goal.

As I'll summarize later we can easily ship a release even today 
including pre refactoring code, we just miss the release manager and 
this is not a matter of solving this issue. We all agree on this, so no 
need to mix the release issue with the repackaging+cycles issues.

No one vetoed any of the proposed solution, so, in fact we are 
discussing to find the best solution, not to find an acceptable 
solution, and this is really good. Everyone can live whatever we decide, 
so let's collect preferences and go with what makes more people not only 
living, but living more happy! :-)

> I don't think there is anything wrong with your communication skills. 
> I'm impressed that you are investing so much of your personal time in 
> trying to make Mime4j a better piece of software. Don't stop doing that! 
> :) The reason why I didn't raise my concerns earlier is that I haven't 
> had the time to catch up until now (I just come back from vacation).

Thank you!

Now I better understand your point and I see we have different (somehow 
diverging) opinions about this.
Unfortunately for me (and trying to find a consensus) this is different 
from Bernd interpretation, so I'll ask you some more questions if you 
don't mind.

Here is an updated summary of what are our current proposed solutions:

A) vote down MIME4J-51 and revert the code change.
    + least surprise
    + no upgrading effort required
    * parser is in main package
    - not good package classification
    - cyclic dependencies

B) move mime4j.* to mime4j.core.* and mime4j.parser.* to mime4j.* (so to 
bring parser classes in the main package).
    + remove cyclic dependencies
    + better packaging
    * parser is in main package
    - BodyDescriptor and MimeException are in a different package than 
before (upgrading issue)
    - MaximalBodyDescriptor is a different package than before 
(upgrading issue, at least for james-server)

C) leave everything as is in trunk (mime4j-51 applied!).
    + remove cyclic dependencies
    + better packaging
    + better organization to host non parsing related code, too.
    * parser is in the parser package
    - most "public" classes are moved around (upgrading issue)
    - main parser classes are in mime4j.parser instead of main.

D) move ContentHandler, AbstractContentHandler, MimeStreamParser, 
MimeTokenStream from parser to main:
    + better packaging
    * parser is in main package
    - cyclic dependencies: introduce 6 new package cycles:
      main => parser => descriptor => field.datetime.parser => main
      main => parser => descriptor => field.mimeversion => main
      main => parser => descriptor => field.structured => main
      main => parser => descriptor => field.language => main
      main => parser => descriptor => main
      main => parser => mime4j
    - MaximalBodyDescriptor is in a differet package (upgrading issue)

There is another option I removed:
X) keep that in trunk for a future release and try to release r680989 
(and reapply r682373 and r682374)
    * this is almost the same of "A" in the short, but already define
      a roadmap for the future (could be "B"/"C"/"D").
I think that everyone agree that the release has the priority on 
everything, so this is a non-option. Regardless from what we or we will 
agree we can release r680989 and reapply r682373 and r682374 at any time.

This is what I think should be used as starting point for a POLL unless 
we find a better agreement, so, before going to a POLL (given that Bernd 
say we should not use polls), can you tell if #3 would work for you by 
fixing the "parser centrality" issue but not fixing the "upgrading issue" ?

The "D" option (your proposal) was not on discussion previously so I can 
only tell what is my current understanding of what people would support. 
Where I don't put more names is because I don't yet know/understand 
their position wrt the given option. Of course this is my personal 
feeling and while I only do my best to understand people I may be wrong 
in interpreting ideas, so everyone is welcome to fix my understanding.

A. -0 bago
B. +0/+1 robert/oleg/bago/bernd.
C. +1 bago/robert -0.5 bernd/niklas
D. -0.5 bago, +1 niklas

If you like "B" I think (based on the above "table" and considerations) 
we could find consensus there, otherwise I would prefer to go the poll 
way so we test for real what people think and we don't have to go 
through my understanding.

Stefano

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


Mime
View raw message