On Fri, 2010-02-12 at 15:16 +0100, Oleg Kalnichevski wrote: > Stefano Bagnara wrote: > > 2010/2/12 Oleg Kalnichevski <[email protected]>: > >> Stefano Bagnara wrote: > >>> 2010/2/11 Oleg Kalnichevski <[email protected]>: > >>>> 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
