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 Thu, 11 Feb 2010 21:14:03 GMT
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

Mime
View raw message