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: dom / message API inconsistency
Date Fri, 12 Feb 2010 12:07:39 GMT
Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <olegk@apache.org>:
>> Stefano Bagnara wrote:
>>> The main difference is that you can add new methods with a default
>>> implementation. If you care of binary compatibility this is a major
>>> difference (but I understand that it make no sense to start talking of
>>> binary compatibility now that we are still moving around classes).
>>> Most JVM classes are not interfaces because of this difference.
>> There are tons of interfaces in JRE especially for newer stuff, so I am not
>> sure this is a very convincing argument.
> I'm not trying to convince you. I don't care what we choose, we just
> have to find an agreement.
> Do you prefer interfaces? go with interfaces. I don't care too much of
> backward compatibility so I don't care of the above issue.
> Really.
>>> That said if you want to merge back the packages I don't care (I
>>> *really* don't like this, but I can accept it). I will split them once
>>> I will have the time for a longer step.
>> I am too old for doing work someone is absolutely determined to undo, so I
>> will not bother. I have no problem of what so ever putting together a very
>> simple DOM-like library based on mime4j for my personal projects. The
>> trouble is that I will no longer be able to continue working towards 0.7
>> release and some one will have to take over from here.
> Sorry but I don't understand.
> If you agree that a dom package (ala org.w3c.dom) is a good thing then
> we should discuss on how to improve it, otherwise we discuss on how to
> not have a dom package.
>>>From your previous comment I thought you agreed that a org.w3c.dom
> like package was good so we have 3 choices:
> 1) leave as is and improve things after 0.7
> 2) improve dom stuff before 0.7
> 3) merge dom to message for 0.7 and refactor later to extract the dom
> package for 0.8
> Otherwise if you don't like the idea of a dom package not depending on
> parser then let's discuss this. Maybe some other developer can say
> what he thinks, as it's easier to have a majority when there are 3
> comments (rather than 2).
>> I am also getting really worried that given the current pace there is
>> absolutely no hope of API stable mime4j any time soon.
> Unfortunately this is how non-paid opensource works. I don't think I
> will have much time soon to improve things. I'll probably work on that
> in future but I don't know when and how.
>> This makes me think
>> about dropping dependency on mime4j in HttpClient. HttpMime uses just a
>> fraction of mime4j functionality, mostly high level, which tends to change a
>> lot. It is a shame, really, but with my HttpClient hat on I cannot help
>> feeling mime4j has become more of a liability.
> I can't help you with this choice. It's hard to understand what blocks
> you from improving mime4j instead of branching it in httpcomponents.
> I didn't hear anyone stopping you from doing anything here.. so it
> seems *weird* to hear that sentence.
>> Having said all that, let's try to be constructive.
> :-)
>> I will leave all
>> 'message' stuff as is, and will _try_ to come up with default
>> implementations for methods in that high level DOM classes that are
>> currently abstract, as long as this can be done without re-introducing
>> dependencies on 'parser' and 'message'. This would enable HttpClient to
>> depend on 'dom' without needing 'message'. If later on you decide to throw
>> away those changes, so be it, I will just fork those classes and that is it.
> If you use mime4j for parsing a stream into a dom you will need the
> message stuff anyway.
> The idea is that you don't need parser if you build the message from
> scratch, but the current implementation rely on a "weird" behaviour so
> that when you create a field it creates the stream representation and
> then parse it into a structured field. And parsing logic for fields
> rely on some parser-module packages.
> So, there's no need to fork now: do exactly what you need for mime4j
> 0.7 (I care of the DecodeMonitor stuff, nothing else now) so that you
> can release it and keep using it in httpclient. We'll discuss any
> possible improvement after that.
> I have the feeling you don't like to discuss with me. I have my
> opinions and I usually defend my opinions when I discuss, but I like
> collaboration and team work and I'm happy to accept that people have
> different opinions.
> I'm currently busy and the next week I'll be on holiday so I can't
> better explain how I think dom should work. We already saw the
> community wants fixes for mime4j (we had a lot of reports about the
> wordencoded stuff) so it's far better you work on releasing 0.7 the
> way you think it's better,than keep waiting I will have time to
> elaborate.
> Stefano


After another failed attempt at finding ways to make peace with the 
dom/message split up, I am giving up. While I still believe it would be 
great to be able to build messages with 'dom' only without needing 
'core', but I found it impractical mainly due to dependency on 
o.a.j.m.util classes.

Please bring your work to a logical conclusion once you have time. 
Mime4j is all yours now.



View raw message