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 Tue, 29 Jun 2010 11:55:23 GMT
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 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


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. If
my opinion matters, mime4j ought not be released in its present shape.

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.

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



View raw message