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 Tue, 29 Jun 2010 12:14:24 GMT
2010/6/29 Oleg Kalnichevski <olegk@apache.org>:
> On Mon, 2010-06-28 at 23:50 +0200, Stefano Bagnara wrote:
>> 2010/6/25 Oleg Kalnichevski <olegk@apache.org>:
>> > 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
>> >> > 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
>> >> > 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,

View raw message