james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: dom / message API inconsistency
Date Thu, 01 Jul 2010 12:04:21 GMT
Hi Oleg,

like Stefano said feel free to revert his changes and just go ahead
and work on it in trunk.. Just tag it before you revert, so we can
pick up on this if we feel like it will be a good fit later.

There is no need for you to fork, I would like to see you work on it
here and then cut a release.



Bye,
Noeman


2010/6/29 Oleg Kalnichevski <olegk@apache.org>:
> On Tue, 2010-06-29 at 14:14 +0200, Stefano Bagnara wrote:
>> 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 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.
>
> Right, because most likely all the necessary 'message' stuff gets
> quietly pulled in through the MessageBuilderFactory, which I personally
> cannot see as an improvement.
>
>>  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" :-)
>>
>
> Every time decisions are made based on subjective opinions and
> perceptions are there can be no backward and forward. Someone's
> 'forward' may well happen to be 'backward' for others and the other way
> around.
>
>> 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.
>>
>
> Likewise, I personally see no issue taking a snapshot of mime4j core to
> GitHub and building an ultra trivial message API on top of it. I just
> hoped this could be avoided, though.
>
> Cheers
>
> Oleg
>
>

Mime
View raw message