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 14:16:59 GMT
Stefano Bagnara wrote:
> 2010/2/12 Oleg Kalnichevski <olegk@apache.org>:
>> 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
>> 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.
> - IMO priority is releasing 0.7.
> - I'll be on holiday next week and generally busy, so you'll have to
> take care of 0.7 release
> - Do whatever you think is appropriate in order to release 0.7 (if you
> need to merge dom to message simply do that). Generally speaking I'd
> like httpclient to keep using mime4j, so shape it the way it works for
> you. My only requirement for 0.7 is not to reintroduce package
> dependency cycles).
> If you, instead, decide to leave stuff as is then later (0.8) we can
> add a MessageBuilderFactory/MessageBuilder to the dom package and make
> them default (via property file) to MessageImpl from the message
> package. After this addition an external user should not have the need
> to work with the message/field packages (and in case it still happen
> we should consider adding methods to the builder or to the other dom
> classes).
> Stefano

Personally I am not in favor of cutting a new release unless we are done 
moving stuff around. If you need time, take your time.


View raw message