james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: dom / message API inconsistency
Date Fri, 12 Feb 2010 13:43:09 GMT
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


View raw message