dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

Stefano

I am trying to any make sense out of dom / message package split and I
just can't.

What is the rationale behind splitting Message, Multipart and related
classes?

Why does HeaderImpl extend a concrete class, whereas MessageImpl extends
an abstract class? Why does Multipart have to be abstract at all? Do we
need MultipartImpl at all? 

Why HeaderImpl, MultipartImpl, and MessageImpl are called impls when
they are NOT implementations of an interface but are merely extensions
of other classes, some of which are not even abstract? Is such extension
really justified?

What was the philosophy and the intention behind these API changes?

I am lost. Please help me out.

Oleg

Re: dom / message API inconsistency

[Norman Maurer <no...@apache.org>]

I will try to See whats needed in terms of imap....

Bye
Norman

2010/6/28, Stefano Bagnara <ap...@bago.org>:
> 2010/6/25 Oleg Kalnichevski <ol...@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
>

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/6/29 Oleg Kalnichevski <ol...@apache.org>:
> 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.

For what it worth I chose abstract classes instead of interfaces in
order to be able to keep better backward compatibility when we'll
start adding more methods to the DOM.

If we rely on interfaces then each method we add will break compatibility.

That said this is only an explanation of the choice, it doesn't mean
I'm against any other approach or that you can't wipe everything :-)

Stefano

Re: dom / message API inconsistency

[Norman Maurer <no...@apache.org>]

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

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

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

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

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

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

On Mon, 2010-06-28 at 23:50 +0200, Stefano Bagnara wrote:
> 2010/6/25 Oleg Kalnichevski <ol...@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. 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
anymore.

Cheers

Oleg 

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/6/25 Oleg Kalnichevski <ol...@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

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

On Fri, 2010-02-12 at 15:16 +0100, Oleg Kalnichevski wrote:
> Stefano Bagnara wrote:
> > 2010/2/12 Oleg Kalnichevski <ol...@apache.org>:
> >> Stefano Bagnara wrote:
> >>> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> >>>> 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 

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

Stefano Bagnara wrote:
> 2010/2/12 Oleg Kalnichevski <ol...@apache.org>:
>> Stefano Bagnara wrote:
>>> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
>>>> 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

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/2/12 Oleg Kalnichevski <ol...@apache.org>:
> Stefano Bagnara wrote:
>>
>> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
>>>
>>> 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

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
>> 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.

Cheers

Oleg

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> 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

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
>> On Thu, 2010-02-11 at 15:53 +0100, Stefano Bagnara wrote:
>>> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
>>>> In my opinion we should either make DOM API truly abstract by making
>>>> Message, Multipart, Header and friends interfaces or give up any
>>>> pretense at DOM being an abstract API, which it is clearly not.
>>> Well, Multipart is already abstract and in the dom. Header is not used
>>> anywhere (ATM). Message have an abstract code.
>> Just declaring stuff abstract, does not not necessarily make it
>> abstract, does it? Even though those classes are declared abstract they
>> have too much implementation specific code in them to be truly abstract
>> in terms of being implementation neutral. At the moment those classes
>> are not abstract, they are useless (without 'message' impls).
>>
>>>  About using abstract
>>> classes instead of interfaces this is a design choices: there are
>>> pros/cons. With abstract classes you can add methods later without
>>> breaking implementations. An interface only API will break
>>> compatibility at every change (that's why I chose to start with
>>> abstract for many classes).
>>>
>> One cannot add new abstract methods without breaking API compatibility,
>> so I do not see much of a difference here.
> 
> 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.


>>> What I did was a first step towards the first solution. I agree it is
>>> not complete, and to complete it we have to take design decisions like
>>> these:
>>> 1) ParsedField isValidField/getParseException should be really part of
>>> the dom or a dom should only represent valid content?
>>> 2) Do we want to mimic the xml stuff so provide a MessageBuilder (not
>>> the MessageBuilder we have now but a MessageBuilder similar to the xml
>>> DocumentBuilder.. and maybe a MessageBuilderFactory) with a parse
>>> method that return a Message? or what else?
>>> 3) About message serialization: "object.writeTo" allow for
>>> optimizations when the implementation knows original bytes for parsed
>>> data. MessageWriter, instead is more similar to the
>>> javax.xml.transform.Transformer stuff (well, we could even have a
>>> "Writeable" interface and when MessageWriter finds writable objects it
>>> optimize the writing process (didn't think about this too much).
>>>
>>> IMO the goal is to have a mime dom manipulation library not depending
>>> on the parser: this would make the mime4j architecture more clear. TO
>>> make the "dom" usable we just need a MessageBuilder (and maybe
>>> MessageBuilderFactory) object. My use case is:
>>> MessageBuilder mb = MessageBuilderFactory.newMessageBuilder();
>>> Message m = mb.parse(InputrStream);
>>> Also, I'd like to have a MessageBuilder.newMessage instead of new MessageImpl().
>>> At this point I should be able to use/alter the message without using
>>> the message/field packages, but only the dom package.
>>>
>> Ability to use 'dom' package to generate messages without depending on
>> the 'parser' package is a great idea, which I fully support, but the
>> current state of things does not take us any further towards that goal
>> than before the refactoring.
> 
> I think a roadmap is made by steps. Most time you need multiple steps
> to reach a good results, but this doesn't mean you should not move
> your feets until you know you can jump to the good results.
> 
> 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.
> 
> Stefano
> 

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.

I am also getting really worried that given the current pace there is 
absolutely no hope of API stable mime4j any time soon. 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.

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.

Cheers

Oleg

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> On Thu, 2010-02-11 at 15:53 +0100, Stefano Bagnara wrote:
>> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
>> > In my opinion we should either make DOM API truly abstract by making
>> > Message, Multipart, Header and friends interfaces or give up any
>> > pretense at DOM being an abstract API, which it is clearly not.
>>
>> Well, Multipart is already abstract and in the dom. Header is not used
>> anywhere (ATM). Message have an abstract code.
>
> Just declaring stuff abstract, does not not necessarily make it
> abstract, does it? Even though those classes are declared abstract they
> have too much implementation specific code in them to be truly abstract
> in terms of being implementation neutral. At the moment those classes
> are not abstract, they are useless (without 'message' impls).
>
>>  About using abstract
>> classes instead of interfaces this is a design choices: there are
>> pros/cons. With abstract classes you can add methods later without
>> breaking implementations. An interface only API will break
>> compatibility at every change (that's why I chose to start with
>> abstract for many classes).
>>
>
> One cannot add new abstract methods without breaking API compatibility,
> so I do not see much of a difference here.

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.

>> What I did was a first step towards the first solution. I agree it is
>> not complete, and to complete it we have to take design decisions like
>> these:
>> 1) ParsedField isValidField/getParseException should be really part of
>> the dom or a dom should only represent valid content?
>> 2) Do we want to mimic the xml stuff so provide a MessageBuilder (not
>> the MessageBuilder we have now but a MessageBuilder similar to the xml
>> DocumentBuilder.. and maybe a MessageBuilderFactory) with a parse
>> method that return a Message? or what else?
>> 3) About message serialization: "object.writeTo" allow for
>> optimizations when the implementation knows original bytes for parsed
>> data. MessageWriter, instead is more similar to the
>> javax.xml.transform.Transformer stuff (well, we could even have a
>> "Writeable" interface and when MessageWriter finds writable objects it
>> optimize the writing process (didn't think about this too much).
>>
>> IMO the goal is to have a mime dom manipulation library not depending
>> on the parser: this would make the mime4j architecture more clear. TO
>> make the "dom" usable we just need a MessageBuilder (and maybe
>> MessageBuilderFactory) object. My use case is:
>> MessageBuilder mb = MessageBuilderFactory.newMessageBuilder();
>> Message m = mb.parse(InputrStream);
>> Also, I'd like to have a MessageBuilder.newMessage instead of new MessageImpl().
>> At this point I should be able to use/alter the message without using
>> the message/field packages, but only the dom package.
>>
>
> Ability to use 'dom' package to generate messages without depending on
> the 'parser' package is a great idea, which I fully support, but the
> current state of things does not take us any further towards that goal
> than before the refactoring.

I think a roadmap is made by steps. Most time you need multiple steps
to reach a good results, but this doesn't mean you should not move
your feets until you know you can jump to the good results.

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.

Stefano

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

On Thu, 2010-02-11 at 15:53 +0100, Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> > In my opinion we should either make DOM API truly abstract by making
> > Message, Multipart, Header and friends interfaces or give up any
> > pretense at DOM being an abstract API, which it is clearly not.
> 
> Well, Multipart is already abstract and in the dom. Header is not used
> anywhere (ATM). Message have an abstract code.

Just declaring stuff abstract, does not not necessarily make it
abstract, does it? Even though those classes are declared abstract they
have too much implementation specific code in them to be truly abstract
in terms of being implementation neutral. At the moment those classes
are not abstract, they are useless (without 'message' impls). 

>  About using abstract
> classes instead of interfaces this is a design choices: there are
> pros/cons. With abstract classes you can add methods later without
> breaking implementations. An interface only API will break
> compatibility at every change (that's why I chose to start with
> abstract for many classes).
> 

One cannot add new abstract methods without breaking API compatibility,
so I do not see much of a difference here.  


> What I did was a first step towards the first solution. I agree it is
> not complete, and to complete it we have to take design decisions like
> these:
> 1) ParsedField isValidField/getParseException should be really part of
> the dom or a dom should only represent valid content?
> 2) Do we want to mimic the xml stuff so provide a MessageBuilder (not
> the MessageBuilder we have now but a MessageBuilder similar to the xml
> DocumentBuilder.. and maybe a MessageBuilderFactory) with a parse
> method that return a Message? or what else?
> 3) About message serialization: "object.writeTo" allow for
> optimizations when the implementation knows original bytes for parsed
> data. MessageWriter, instead is more similar to the
> javax.xml.transform.Transformer stuff (well, we could even have a
> "Writeable" interface and when MessageWriter finds writable objects it
> optimize the writing process (didn't think about this too much).
> 
> IMO the goal is to have a mime dom manipulation library not depending
> on the parser: this would make the mime4j architecture more clear. TO
> make the "dom" usable we just need a MessageBuilder (and maybe
> MessageBuilderFactory) object. My use case is:
> MessageBuilder mb = MessageBuilderFactory.newMessageBuilder();
> Message m = mb.parse(InputrStream);
> Also, I'd like to have a MessageBuilder.newMessage instead of new MessageImpl().
> At this point I should be able to use/alter the message without using
> the message/field packages, but only the dom package.
> 

Ability to use 'dom' package to generate messages without depending on
the 'parser' package is a great idea, which I fully support, but the
current state of things does not take us any further towards that goal
than before the refactoring. 

Oleg


> I don't think that the w3c.dom/javax.xml.parsers stuff is perfect but
> their patterns are good and very well known so I'm using the principle
> of the least surprise.
> 
> Of course this is just my opinion, I'm just one developer and I'm open
> to discussions (and expecially to "majority" choices).
> 
> Stefano
> 
> PS: please forgive me for using MessageBuilder (a name we already have
> in mime4j) for a new concept instead of using a new name, but I hope
> it's clear I chose MessageBuilder to make a parallel with the
> javax.xml.parsers.DocumentBuilder object.
> 

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> In my opinion we should either make DOM API truly abstract by making
> Message, Multipart, Header and friends interfaces or give up any
> pretense at DOM being an abstract API, which it is clearly not.

Well, Multipart is already abstract and in the dom. Header is not used
anywhere (ATM). Message have an abstract code. About using abstract
classes instead of interfaces this is a design choices: there are
pros/cons. With abstract classes you can add methods later without
breaking implementations. An interface only API will break
compatibility at every change (that's why I chose to start with
abstract for many classes).

What I did was a first step towards the first solution. I agree it is
not complete, and to complete it we have to take design decisions like
these:
1) ParsedField isValidField/getParseException should be really part of
the dom or a dom should only represent valid content?
2) Do we want to mimic the xml stuff so provide a MessageBuilder (not
the MessageBuilder we have now but a MessageBuilder similar to the xml
DocumentBuilder.. and maybe a MessageBuilderFactory) with a parse
method that return a Message? or what else?
3) About message serialization: "object.writeTo" allow for
optimizations when the implementation knows original bytes for parsed
data. MessageWriter, instead is more similar to the
javax.xml.transform.Transformer stuff (well, we could even have a
"Writeable" interface and when MessageWriter finds writable objects it
optimize the writing process (didn't think about this too much).

IMO the goal is to have a mime dom manipulation library not depending
on the parser: this would make the mime4j architecture more clear. TO
make the "dom" usable we just need a MessageBuilder (and maybe
MessageBuilderFactory) object. My use case is:
MessageBuilder mb = MessageBuilderFactory.newMessageBuilder();
Message m = mb.parse(InputrStream);
Also, I'd like to have a MessageBuilder.newMessage instead of new MessageImpl().
At this point I should be able to use/alter the message without using
the message/field packages, but only the dom package.

I don't think that the w3c.dom/javax.xml.parsers stuff is perfect but
their patterns are good and very well known so I'm using the principle
of the least surprise.

Of course this is just my opinion, I'm just one developer and I'm open
to discussions (and expecially to "majority" choices).

Stefano

PS: please forgive me for using MessageBuilder (a name we already have
in mime4j) for a new concept instead of using a new name, but I hope
it's clear I chose MessageBuilder to make a parallel with the
javax.xml.parsers.DocumentBuilder object.

Re: dom / message API inconsistency

[Oleg Kalnichevski <ol...@apache.org>]

On Thu, 2010-02-11 at 10:35 +0100, Stefano Bagnara wrote:
> 2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> > Stefano
> >
> > I am trying to any make sense out of dom / message package split and I
> > just can't.
> 
> I understand, I still have to find a way, too.
> 
> > What is the rationale behind splitting Message, Multipart and related
> > classes?
> >
> > Why does HeaderImpl extend a concrete class, whereas MessageImpl extends
> > an abstract class? Why does Multipart have to be abstract at all? Do we
> > need MultipartImpl at all?
> >
> > Why HeaderImpl, MultipartImpl, and MessageImpl are called impls when
> > they are NOT implementations of an interface but are merely extensions
> > of other classes, some of which are not even abstract? Is such extension
> > really justified?
> >
> > What was the philosophy and the intention behind these API changes?
> 
> dom package include generic code not tied to other mime4j packages and
> mime4j specific parsing.
> IMO it is the quivalent of the org.w3c.dom package.
> 

Presently Dom API is not abstract enough to qualify as an equivalent of
org.w3c.dom, yet missing essential method implementations to be of any
use without message classes. I just cannot help feeling the break-up
into dom and message does not result in any practical benefits.


> This is the only rule I started following when I split the code into
> dom. Previously we had much more mixed environment with the field
> paclage tree containing both implementation details, interface,
> constants, entry points and everything interconnected to the message
> package.
> 
> That said the whole thing is not good, but better than previously. If
> you think the idea behind generic api in the dom package and
> implementation in message/field packages then feel free to go ahead
> and make changes, otherwise let's discuss alternatives.
> 
> 

In my opinion we should either make DOM API truly abstract by making
Message, Multipart, Header and friends interfaces or give up any
pretense at DOM being an abstract API, which it is clearly not.  

Oleg

 
> 
> 
> Stefano
> 

Re: dom / message API inconsistency

[Stefano Bagnara <ap...@bago.org>]

2010/2/11 Oleg Kalnichevski <ol...@apache.org>:
> Stefano
>
> I am trying to any make sense out of dom / message package split and I
> just can't.

I understand, I still have to find a way, too.

> What is the rationale behind splitting Message, Multipart and related
> classes?
>
> Why does HeaderImpl extend a concrete class, whereas MessageImpl extends
> an abstract class? Why does Multipart have to be abstract at all? Do we
> need MultipartImpl at all?
>
> Why HeaderImpl, MultipartImpl, and MessageImpl are called impls when
> they are NOT implementations of an interface but are merely extensions
> of other classes, some of which are not even abstract? Is such extension
> really justified?
>
> What was the philosophy and the intention behind these API changes?

dom package include generic code not tied to other mime4j packages and
mime4j specific parsing.
IMO it is the quivalent of the org.w3c.dom package.

This is the only rule I started following when I split the code into
dom. Previously we had much more mixed environment with the field
paclage tree containing both implementation details, interface,
constants, entry points and everything interconnected to the message
package.

That said the whole thing is not good, but better than previously. If
you think the idea behind generic api in the dom package and
implementation in message/field packages then feel free to go ahead
and make changes, otherwise let's discuss alternatives.

Stefano