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

[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