2010/6/29 Oleg Kalnichevski <[email protected]>: > On Mon, 2010-06-28 at 23:50 +0200, Stefano Bagnara wrote: >> 2010/6/25 Oleg Kalnichevski <[email protected]>: >> > On Fri, 2010-02-12 at 15:16 +0100, Oleg Kalnichevski wrote: >> >> Stefano Bagnara wrote: >> >> > - 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 >> >> Hi Oleg, unfortunately I had very few time for mime4j and currently >> I'm busy on datawarehousing stuff, so nothing near James :-( >> >> As you probably saw a couple of months ago I introduced a basic >> factory for the dom api and I refactored jdkim (and some internal >> projects) to use that methods (and tests everything worked as >> expected). I just saw I had some minor uncommitted change, too, so I >> took some minutes to run the test suites for mime4j and downstreams >> and commit them. Few weeks ago I tried checking out james-imap to try >> upgrading mime4j and see what we needed on that side (and if the >> upgrade didn't break everthing), but imap is changing too fast for my >> current pace (at this time I see failures but I'm not sure they are >> not in imap itself) >> >> For my use cases (read only DOM) it works fine, but It doesn't sound >> as a complete/stable api, if you ask me. It's better than ever in >> past, but not complete. In fact we are calling it 0.7-SNAPSHOT, not >> 1.0. >> >> I think the current code represents a step forward from 0.6, but I >> still think releasing is the priority (as it was 5 months ago) but I >> can't afford the process right now, so until someone will jump in for >> this task I'll keep adding my small improvements to the code when I >> happen to have them ready. >> >> If anyone has suggestions on how to improve the code or anyone wants >> to drive a 0.7 release (including whatever content or even reverting >> to any point in past) I'm happy to discuss it in my spare time. >> >> Now that we have modules we could concentrate on stabilizing the >> "core" module and leave the dom module as an evolving platform. I'm >> not an "advanced user" of the core module, so I don't know what is >> needed to make it better (we already did the critical improvements in >> current trunk). >> >> Now it's my turn for the questions ;-) . What about your plans? >> >> Stefano >> > > Stefano, > > With all due respect, to me DOM/message API still looks helplessly > broken. In its present form 'dom' does not represent a coherent abstract > interface. It is just a bunch of concrete classes with random bits > ripped out, which are completely useless without 'message' classes.
As I explained for the read only case I'm using the dom package without viewing the message package. You can see this at least in jdkim, but I did something similar in a couple of internal projects too. I admit I have very limited requirement but from my use case the new packages are much better than before. > If > my opinion matters, mime4j ought not be released in its present shape. Of course your opinion matter. And it matters at least as much as mine :-) > My personal preference would be to revert the changes made to the > 'dom'/'message' classes, but since you said you would immediately start > over as soon as you had a chance, I do not see a point doing so. Feel free to revert. When/If I'll find more time for mime4j I'll look at the state and decide whether it is still able to satisfy my needs or not. At the moment I have at least 2 projects depending on the "trunk" so if you revert I can either local-branch or mantain a branch in the mime4j/branches folder (as you prefer). > I have time and a real need to work on the next mime4j release, but > currently do not see any possible way to contribute to the project > anymore. Why? if you have time please jump in and move mime4j forward. Just start showing what is your "forward" :-) If you need to revert anything in order to move forward just do it. As I'm not going to be fast on discussions feel free to "tag/branch" trunk (for me, please, so I don't have to remember the right revison where we "reverted") and to make your changes directly in trunk! I worked in trunk with the same principle: things should happen in trunk. If anything is wrong we can revert and start again. I hope/guess that some of my commits since mime4j 0.6 will be useful for the next release, but I won't be hurted if you wipe all of my commits. As long as we "attack" code and not people everything will work fine, and you already proved that you look at code :-) Thank you, Stefano
