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, 25 Jun 2010 10:49:11 GMT
On Fri, 2010-02-12 at 15:16 +0100, Oleg Kalnichevski wrote:
> 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.
> 
> Oleg
> 


Stefano,

It has been almost 5 months. Is there still any change of dom / message
API getting fixed in a foreseeable future?

Oleg 



Mime
View raw message