Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Robert Burrell Donkin <ro...@gmail.com>]

On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:

<snip>

> >> IMHO it worth specifying that this is not the panacea because this means
> >> that backward incompatible changes in core stuff will not be supported
> >> unless you clone all of the modules.
> >
> > that what you mean by core. an example would be useful.
>
> There are old refactorings that have been delayed forever because of
> introduced incompatibilities.
> - One of them is mailet api changes: when you change the mailet api you
> probably need to change a lot of code in james.

IMHO this is now a matter for the mailet subproject. once a new API
has been agreed and released, then we can work out what to do about
the server.

> - One is the Message/Envelope change and the refactoring of mail/spool
> repositories interfaces: again there is many code bound to this interfaces.

i don't understand the proposal in detail. however, it's usually
possible to preserve only storage/configuration compatibility (and not
code binary compatibility) by add the new API as an extra interface
but without knowing more about the proposal, i don't know whether it
would be possible in this case.

> - One is complete DNS support (requires changes in mailet api, in
> smtpserver, in the spoolmanager and in the remote delivery) [trivia: I
> joined JAMES mainly to add DSN support to it].

i don't understand why this would necessarily break
storage/configuration compatibility

> - probably there are many more I don't remember now.
>
> Btw, as you pointed out, maybe I'm too much worried about this as it
> seems as no one have this issues in the roadmap anymore.

that's because i'm very carefully not to propose a roadmap ;-)

the road to 3.0 will lead to where ever people want it go

> > dubbing trunk 3.0 (rather than next-major) does not include or exclude
> > a commitment to maintaining backwards compatibility. it consists of
> > nothing more or less than deciding to adopt a new label. when someone
> > wants to make a change that is not backwards compatible then this is
> > when we should make a decision.
>
> You "lead" this effort now, so let's play your game :-)

i'm not leading anything :-)

i'm just doing what seems right to me

dubbing the trunk 3.0 seems a logical step right now so i proposed it

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Danny Angus <da...@apache.org>]

On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:

> ok. What I mean is that one question could be: is a new mailet api still
> in a roadmap for 3.0 ? It was one of the main point in past (not in my
> roadmap). Danny: if you are tuned what's your idea about this?

The enw API will have its own lifecycle, and I don't know what our
timescales are right now.
But I do plan to do something with repository interfaces, so I guess I
should start thinking about a plan.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Danny Angus <da...@apache.org>]

On 8/2/07, Stefano Bagnara <ap...@bago.org> wrote:
> Danny Angus ha scritto:

> I don't remember anyone suggesting the modularisation as a solution to
> our problems (at least since I joined JAMES, that is before the problems
> started anyway ;-) ).

I don't think anyone did, but there was an understanding that we
needed to make architectural changes if we wanted to solve problems
like avalon demise, and finishing imap.

> Not that proving that it was discussed or not will solve anything now,
> but I'm very "sensible" to interpretations of the past and I think that
> my statement was "strictly true" ;-).

Chill out, I don't think it really matters, I'm just making the point
that robert wasn't the first person to think about this, nor was his
motivation the only one.

d.

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

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

Danny Angus ha scritto:
> On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>> You seems so secure about what happened and what was the problem.
>> There has never been stealth in my behaviour. NEVER: I'd like to know
>> how did you created such opinion (hope not talking with Noel or Danny,
>> but instead reading some old thread)
>> If you are really right then it was a pity that no one understood this
>> in the last 2 years and no one proposed such a solution.
> 
> Thats not strictly true, we have long understood the need to break
> James up, robert just happened to be motivated to actually do it.

I don't remember anyone suggesting the modularisation as a solution to
our problems (at least since I joined JAMES, that is before the problems
started anyway ;-) ).

I just ran a search about this and only found a message from me on 24
May 2006, titled "Maven2 opinions" [1] including a point #4: "It will
allow us to split James in subprojects: mailet-api, mailet-impl, core,
smtp, pop3, nntp, fetchmail, mailets, spoolmanager having well-defined
dependencies between modules. This will improve the self-documentation
provided by james sourcecode (it makes much more clear the modules and
the dependencies) and maybe a step towards OSGi bundles." (context: at
that time many PMC members liked osgi and I was proposing maven because
it was simpler to me and my skills to achieve modularization via this
tool instead of ant). I suggest anyone reading that maven2 thread now,
it is interesting to see how much I was ignoring others' opinions.

The previous reference I can find is from january 2005 (notice it is
more than 2 years ago) and it was about "James-NG" [2] that is something
that probably was discussed before I joined the team because no one
talked about this after that date.

Not that proving that it was discussed or not will solve anything now,
but I'm very "sensible" to interpretations of the past and I think that
my statement was "strictly true" ;-).

Stefano

[1]
http://www.mail-archive.com/search?l=server-dev%40james.apache.org&q=Maven2+opinions

[2]
http://www.mail-archive.com/search?l=server-dev%40james.apache.org&q=James-NG


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Danny Angus <da...@apache.org>]

On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:

> > you wanted a revolution but ended up evolving the existing code base.
> > architecture by stealth typically creates community issues and so is
> > best avoided.

...

> You seems so secure about what happened and what was the problem.
> There has never been stealth in my behaviour. NEVER: I'd like to know
> how did you created such opinion (hope not talking with Noel or Danny,
> but instead reading some old thread)
> If you are really right then it was a pity that no one understood this
> in the last 2 years and no one proposed such a solution.

Thats not strictly true, we have long understood the need to break
James up, robert just happened to be motivated to actually do it.

> I still don't think *this* was the solution to the problem, but I will
> be happy to be convinced by facts.
>
> >> Btw this is a non-issue as long as no one is currently working on core
> >> stuff.
> >
> > it all depends on what you mean by core stuff. the changes you're
> > proposing are entirely peripheral to me. it sounds to me that your
> > proposal could be easily including in the existing code base by
> > revolutionary forking of the spool management module.
>
> We will discuss again about this once you will have had the opportunity
> to work more on core interfaces/libraries ;-)
>
> >>> i'm just doing what seems right to me
> >> We all know you're pushing your own goals :-P :-P
> >
> > everyone has their own itches to scratch: mine is a working IMAP but
> > i'm not particularly bothered whether it's released or not
>
> I was joking.
>
> > with my apache hat on, i'd like to see the JAMES community stronger
> > and healthier so i'm willing to do what i can to help
> >
> > - robert
>
> This was my main goal, too: I dedicated a lot of my time trying to help
> new people joining JAMES. I really hope Norman, Joachim and Bernd
> recognized this.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

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

Robert Burrell Donkin ha scritto:
>> The same happened from 2.2 to 2.3 when I had to brake config.xml
>> compatibility so to have a better architecture in 2.3. Currently the
>> "goal" was even more ambitious than the 2.3 as we wanted to introduce
>> much more new things but without braking config.xml compatibility.
> 
> this is a classic case of evolution verses revolution
> 
> you wanted a revolution but ended up evolving the existing code base.
> architecture by stealth typically creates community issues and so is
> best avoided.
> 
> given a more modular structure for the server, it should be possible
> to include revolutionary forks within trunk. subversion is very
> flexible and bug fixes made in the base can be merged to the fork.
> backwards compatibility can then be maintain by using the more mature
> code as default.

You seems so secure about what happened and what was the problem.
There has never been stealth in my behaviour. NEVER: I'd like to know
how did you created such opinion (hope not talking with Noel or Danny,
but instead reading some old thread)
If you are really right then it was a pity that no one understood this
in the last 2 years and no one proposed such a solution.
I still don't think *this* was the solution to the problem, but I will
be happy to be convinced by facts.

>> Btw this is a non-issue as long as no one is currently working on core
>> stuff.
> 
> it all depends on what you mean by core stuff. the changes you're
> proposing are entirely peripheral to me. it sounds to me that your
> proposal could be easily including in the existing code base by
> revolutionary forking of the spool management module.

We will discuss again about this once you will have had the opportunity
to work more on core interfaces/libraries ;-)

>>> i'm just doing what seems right to me
>> We all know you're pushing your own goals :-P :-P
> 
> everyone has their own itches to scratch: mine is a working IMAP but
> i'm not particularly bothered whether it's released or not

I was joking.

> with my apache hat on, i'd like to see the JAMES community stronger
> and healthier so i'm willing to do what i can to help
> 
> - robert

This was my main goal, too: I dedicated a lot of my time trying to help
new people joining JAMES. I really hope Norman, Joachim and Bernd
recognized this.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

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

Robert Burrell Donkin ha scritto:
> On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Btw I think we already have much simpler tasks to be solved first, like
>> removing the User from the imap-api module so to not have core-library
>> to depend on imap-api, then we can see how other refactorings will
>> impact on this multi module layout.
> 
> FYI
> http://svn.apache.org/viewvc/james/server/trunk/core-library/src/main/java/org/apache/james/services/
> been back for 6 weeks
> 
> - robert

My bad, this prove I've lost at least one of your commits! now no one
will believe me anymore when I repeat that I read every commit diff ;-)

Cool!
I've just locally updated the maven descriptors to remove the dependency
(commit delayed until excalibur releases the new cornerstone jars)!

Thank you,
Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/1/07, Stefano Bagnara <ap...@bago.org> wrote:

<snip>

> Btw I think we already have much simpler tasks to be solved first, like
> removing the User from the imap-api module so to not have core-library
> to depend on imap-api, then we can see how other refactorings will
> impact on this multi module layout.

FYI

http://svn.apache.org/viewvc/james/server/trunk/core-library/src/main/java/org/apache/james/services/

been back for 6 weeks

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

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

Bernd Fondermann ha scritto:
> Stefano Bagnara wrote:
>>> On 8/1/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>>>> this is a classic case of evolution verses revolution
>>>>
>>>> you wanted a revolution but ended up evolving the existing code base.
>>>> architecture by stealth typically creates community issues and so is
>>>> best avoided.
>>
>> Bernd Fondermann wrote:
>>> +1
>>>
>>> Thanks, Robert. Great post!
>>
>> Bernd, can you just tell me if the +1 was also specific to the sentence
>> above? (as a specific reference to what I did in the last 2 years in
>> JAMES Server).
> 
> No it wasn't.
> I think Robert's analysis to be correct and unbiased. I now believe to
> understand what went wrong and why and how it can be avoided.
> I don't read the sentence you picked up as personal criticism of anyone.

the sentence started with "you": either I am a single part of the plural
you, or I am the singular you ;-)
Maybe "architecture by stealth" is not something negative as I read it,
but I'm happy anyway to have asked this and to have received this answer
(google didn't help me with the definition).

> Generally speaking, looking into the past is only useful when learning
> for the future.

I agree. That's why I'm still talking about this topics even if I don't
have concrete plans on JAMES anymore. I want to be sure I understood
what happened and what is the opinions of others about what happened
(expecially related to my mistakes).

And anyway, I wouldn't be offended by Robert criticisms, as he was not
here, so can only guess what happened. I, sometimes, feel disappointed
by words spoken by people that was here and saw what happened.

> The modularisation in fact opens the possibility for everyone to be
> represented here in source code - the conservative, the evolutionary and
> even the revolutionary - the fast and the slow - the pro-compatibility
> and the con-compatibility.
> 
> It's a technical trick to unsnare - to allow for people with different
> goals to participate (or to not participate, in the sense of not to
> block progress). It works for the moment, at least.
> 
>   Bernd

My personal opinion is that it is working really good at the moment, but
mainly because there is no concurrency and there is no ongoing
refactoring on old code. Excluding the spring module you are porting and
IMAP (both things where not part of 2.3.x) we had no single bug
fixed/feature added in the last 8 months in existing modules of trunk:
many of the refactorings we did in trunk before the modularizations
would have required changes in all of the modules anyway.

I will agree that the modularization is the solution to our problems
when I will start seeing the core to be evolved at the same rhythm we
did it in past. In the mean time I can only enjoy the better structure,
but I can't perceive this big panacea you all see, yet.

Btw I think we already have much simpler tasks to be solved first, like
removing the User from the imap-api module so to not have core-library
to depend on imap-api, then we can see how other refactorings will
impact on this multi module layout.

Maybe the next rainy weekend I will revamp my old fetchmail proposal and
propose to put there as an experimental-fetchmail, now that we have such
modularization: this way it won't get lost forever in the JIRA attachment.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Bernd Fondermann <bf...@brainlounge.de>]

Stefano Bagnara wrote:
>> On 8/1/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>>> this is a classic case of evolution verses revolution
>>>
>>> you wanted a revolution but ended up evolving the existing code base.
>>> architecture by stealth typically creates community issues and so is
>>> best avoided.
> 
> Bernd Fondermann wrote:
>> +1
>>
>> Thanks, Robert. Great post!
> 
> Bernd, can you just tell me if the +1 was also specific to the sentence
> above? (as a specific reference to what I did in the last 2 years in
> JAMES Server).

No it wasn't.
I think Robert's analysis to be correct and unbiased. I now believe to 
understand what went wrong and why and how it can be avoided.
I don't read the sentence you picked up as personal criticism of anyone.

Generally speaking, looking into the past is only useful when learning 
for the future.

The modularisation in fact opens the possibility for everyone to be 
represented here in source code - the conservative, the evolutionary and 
even the revolutionary - the fast and the slow - the pro-compatibility 
and the con-compatibility.

It's a technical trick to unsnare - to allow for people with different 
goals to participate (or to not participate, in the sense of not to 
block progress). It works for the moment, at least.

   Bernd



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

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

> On 8/1/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>> this is a classic case of evolution verses revolution
>>
>> you wanted a revolution but ended up evolving the existing code base.
>> architecture by stealth typically creates community issues and so is
>> best avoided.

Bernd Fondermann wrote:
> +1
>
> Thanks, Robert. Great post!

Bernd, can you just tell me if the +1 was also specific to the sentence
above? (as a specific reference to what I did in the last 2 years in
JAMES Server).

Thank you,
Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Bernd Fondermann <be...@googlemail.com>]

+1

Thanks, Robert. Great post!

  Bernd

On 8/1/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> > Robert Burrell Donkin ha scritto:
> > > On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> > >> Robert Burrell Donkin ha scritto:
> > >
> > > <snip>
> > >
> > >>>> IMHO it worth specifying that this is not the panacea because this means
> > >>>> that backward incompatible changes in core stuff will not be supported
> > >>>> unless you clone all of the modules.
> > >>> that what you mean by core. an example would be useful.
> > >> There are old refactorings that have been delayed forever because of
> > >> introduced incompatibilities.
> > >> - One of them is mailet api changes: when you change the mailet api you
> > >> probably need to change a lot of code in james.
> > >
> > > IMHO this is now a matter for the mailet subproject. once a new API
> > > has been agreed and released, then we can work out what to do about
> > > the server.
> >
> > ok. What I mean is that one question could be: is a new mailet api still
> > in a roadmap for 3.0 ? It was one of the main point in past (not in my
> > roadmap). Danny: if you are tuned what's your idea about this?
>
> i don't have a roadmap for 3.0 :-)
>
> when people find the energy to create and release an update new mailet
> API then that's the right time to think about how to approach
> integration with JAMES server
>
> > >> - One is the Message/Envelope change and the refactoring of mail/spool
> > >> repositories interfaces: again there is many code bound to this interfaces.
> > >
> > > i don't understand the proposal in detail. however, it's usually
> > > possible to preserve only storage/configuration compatibility (and not
> > > code binary compatibility) by add the new API as an extra interface
> > > but without knowing more about the proposal, i don't know whether it
> > > would be possible in this case.
> >
> > The repository refactoring proposal included both an interface change
> > and a storage change:
> > - re-mapping the Mail object as Envelope + MimeMessage
> > - move around the envelope data in a given storage, while keep "static"
> > mimemessages in another storage.
> >
> > Whether to keep backward compatibility or not probably means duplicating
> > the work or not.
> >
> > As an example in the current trunk code I and Norman spent 50% of our
> > time implementing new features and 50% of the time adding backward
> > compatibility (because it was a voted requirement at that time), so I
> > really talk about something concrete. I think most of the code we
> > changed introduced a backward compatibility issue that we then had to
> > fix (I think Norman will confirm this).
> >
> > We had to introduce many workaround and hacks to keep config.xml
> > compatibility and storage compatibility: when we won't need backward
> > compatibility any more then we (you) can stop wasting resources for this
> > and remove the workarounds.
> >
> > The same happened from 2.2 to 2.3 when I had to brake config.xml
> > compatibility so to have a better architecture in 2.3. Currently the
> > "goal" was even more ambitious than the 2.3 as we wanted to introduce
> > much more new things but without braking config.xml compatibility.
>
> this is a classic case of evolution verses revolution
>
> you wanted a revolution but ended up evolving the existing code base.
> architecture by stealth typically creates community issues and so is
> best avoided.
>
> given a more modular structure for the server, it should be possible
> to include revolutionary forks within trunk. subversion is very
> flexible and bug fixes made in the base can be merged to the fork.
> backwards compatibility can then be maintain by using the more mature
> code as default.
>
> > If more than 1 committer will work on the code I think that it is better
> > to know if they have to keep backward compatibility or not, otherwise
> > you risk to completely waste the resources of one developer that keep
> > backward compatibility while the other simply ignore it.
>
> i agree that a consensus about compatibility is important but this is
> not dependent on the number of developers working on the same code
> base. anyone rewriting existing mature code in place risks vetoing
> changes unless they have established a consensus first.
>
> > Btw this is a non-issue as long as no one is currently working on core
> > stuff.
>
> it all depends on what you mean by core stuff. the changes you're
> proposing are entirely peripheral to me. it sounds to me that your
> proposal could be easily including in the existing code base by
> revolutionary forking of the spool management module.
>
> <snip>
>
> > >> - One is complete DNS support (requires changes in mailet api, in
> > >> smtpserver, in the spoolmanager and in the remote delivery) [trivia: I
> > >> joined JAMES mainly to add DSN support to it].
> > >
> > > i don't understand why this would necessarily break
> > > storage/configuration compatibility
> >
> > DSN requires many changes to mailet api and to core interfaces and
> > requires also to store much more informations. It also require a
> > different approach to spooling: as a consequence keeping the config.xml
> > backward compatible is almost impossible.
>
> then the mailet API is the right place to start
>
> once the API has been revised then we can work out the best approach
> to feeding these changes into the server code base
>
> <snip>
>
> > > i'm just doing what seems right to me
> >
> > We all know you're pushing your own goals :-P :-P
>
> everyone has their own itches to scratch: mine is a working IMAP but
> i'm not particularly bothered whether it's released or not
>
> with my apache hat on, i'd like to see the JAMES community stronger
> and healthier so i'm willing to do what i can to help
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

[Robert Burrell Donkin <ro...@gmail.com>]

On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >
> > <snip>
> >
> >>>> IMHO it worth specifying that this is not the panacea because this means
> >>>> that backward incompatible changes in core stuff will not be supported
> >>>> unless you clone all of the modules.
> >>> that what you mean by core. an example would be useful.
> >> There are old refactorings that have been delayed forever because of
> >> introduced incompatibilities.
> >> - One of them is mailet api changes: when you change the mailet api you
> >> probably need to change a lot of code in james.
> >
> > IMHO this is now a matter for the mailet subproject. once a new API
> > has been agreed and released, then we can work out what to do about
> > the server.
>
> ok. What I mean is that one question could be: is a new mailet api still
> in a roadmap for 3.0 ? It was one of the main point in past (not in my
> roadmap). Danny: if you are tuned what's your idea about this?

i don't have a roadmap for 3.0 :-)

when people find the energy to create and release an update new mailet
API then that's the right time to think about how to approach
integration with JAMES server

> >> - One is the Message/Envelope change and the refactoring of mail/spool
> >> repositories interfaces: again there is many code bound to this interfaces.
> >
> > i don't understand the proposal in detail. however, it's usually
> > possible to preserve only storage/configuration compatibility (and not
> > code binary compatibility) by add the new API as an extra interface
> > but without knowing more about the proposal, i don't know whether it
> > would be possible in this case.
>
> The repository refactoring proposal included both an interface change
> and a storage change:
> - re-mapping the Mail object as Envelope + MimeMessage
> - move around the envelope data in a given storage, while keep "static"
> mimemessages in another storage.
>
> Whether to keep backward compatibility or not probably means duplicating
> the work or not.
>
> As an example in the current trunk code I and Norman spent 50% of our
> time implementing new features and 50% of the time adding backward
> compatibility (because it was a voted requirement at that time), so I
> really talk about something concrete. I think most of the code we
> changed introduced a backward compatibility issue that we then had to
> fix (I think Norman will confirm this).
>
> We had to introduce many workaround and hacks to keep config.xml
> compatibility and storage compatibility: when we won't need backward
> compatibility any more then we (you) can stop wasting resources for this
> and remove the workarounds.
>
> The same happened from 2.2 to 2.3 when I had to brake config.xml
> compatibility so to have a better architecture in 2.3. Currently the
> "goal" was even more ambitious than the 2.3 as we wanted to introduce
> much more new things but without braking config.xml compatibility.

this is a classic case of evolution verses revolution

you wanted a revolution but ended up evolving the existing code base.
architecture by stealth typically creates community issues and so is
best avoided.

given a more modular structure for the server, it should be possible
to include revolutionary forks within trunk. subversion is very
flexible and bug fixes made in the base can be merged to the fork.
backwards compatibility can then be maintain by using the more mature
code as default.

> If more than 1 committer will work on the code I think that it is better
> to know if they have to keep backward compatibility or not, otherwise
> you risk to completely waste the resources of one developer that keep
> backward compatibility while the other simply ignore it.

i agree that a consensus about compatibility is important but this is
not dependent on the number of developers working on the same code
base. anyone rewriting existing mature code in place risks vetoing
changes unless they have established a consensus first.

> Btw this is a non-issue as long as no one is currently working on core
> stuff.

it all depends on what you mean by core stuff. the changes you're
proposing are entirely peripheral to me. it sounds to me that your
proposal could be easily including in the existing code base by
revolutionary forking of the spool management module.

<snip>

> >> - One is complete DNS support (requires changes in mailet api, in
> >> smtpserver, in the spoolmanager and in the remote delivery) [trivia: I
> >> joined JAMES mainly to add DSN support to it].
> >
> > i don't understand why this would necessarily break
> > storage/configuration compatibility
>
> DSN requires many changes to mailet api and to core interfaces and
> requires also to store much more informations. It also require a
> different approach to spooling: as a consequence keeping the config.xml
> backward compatible is almost impossible.

then the mailet API is the right place to start

once the API has been revised then we can work out the best approach
to feeding these changes into the server code base

<snip>

> > i'm just doing what seems right to me
>
> We all know you're pushing your own goals :-P :-P

everyone has their own itches to scratch: mine is a working IMAP but
i'm not particularly bothered whether it's released or not

with my apache hat on, i'd like to see the JAMES community stronger
and healthier so i'm willing to do what i can to help

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]

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

Robert Burrell Donkin ha scritto:
> On 7/31/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
> 
> <snip>
> 
>>>> IMHO it worth specifying that this is not the panacea because this means
>>>> that backward incompatible changes in core stuff will not be supported
>>>> unless you clone all of the modules.
>>> that what you mean by core. an example would be useful.
>> There are old refactorings that have been delayed forever because of
>> introduced incompatibilities.
>> - One of them is mailet api changes: when you change the mailet api you
>> probably need to change a lot of code in james.
> 
> IMHO this is now a matter for the mailet subproject. once a new API
> has been agreed and released, then we can work out what to do about
> the server.

ok. What I mean is that one question could be: is a new mailet api still
in a roadmap for 3.0 ? It was one of the main point in past (not in my
roadmap). Danny: if you are tuned what's your idea about this?

>> - One is the Message/Envelope change and the refactoring of mail/spool
>> repositories interfaces: again there is many code bound to this interfaces.
> 
> i don't understand the proposal in detail. however, it's usually
> possible to preserve only storage/configuration compatibility (and not
> code binary compatibility) by add the new API as an extra interface
> but without knowing more about the proposal, i don't know whether it
> would be possible in this case.

The repository refactoring proposal included both an interface change
and a storage change:
- re-mapping the Mail object as Envelope + MimeMessage
- move around the envelope data in a given storage, while keep "static"
mimemessages in another storage.

Whether to keep backward compatibility or not probably means duplicating
the work or not.

As an example in the current trunk code I and Norman spent 50% of our
time implementing new features and 50% of the time adding backward
compatibility (because it was a voted requirement at that time), so I
really talk about something concrete. I think most of the code we
changed introduced a backward compatibility issue that we then had to
fix (I think Norman will confirm this).

We had to introduce many workaround and hacks to keep config.xml
compatibility and storage compatibility: when we won't need backward
compatibility any more then we (you) can stop wasting resources for this
and remove the workarounds.

The same happened from 2.2 to 2.3 when I had to brake config.xml
compatibility so to have a better architecture in 2.3. Currently the
"goal" was even more ambitious than the 2.3 as we wanted to introduce
much more new things but without braking config.xml compatibility.

If more than 1 committer will work on the code I think that it is better
to know if they have to keep backward compatibility or not, otherwise
you risk to completely waste the resources of one developer that keep
backward compatibility while the other simply ignore it.

Btw this is a non-issue as long as no one is currently working on core
stuff. Imap has never been released and spring support is a new feature,
so there is no problem at all with the in-progress tasks.

I sincerely don't remember what was the status when Norman and I stopped
the work on trunk (maybe the JIRA for next-major can help in this) but I
think we left it in an almost backward compatible state. I've doubt
about the compatibility of case sensitive/insensitive user repositories:
IIRC there was some inconsistencies in the 2.3 behavior that I was not
able to reproduce with the new architecture.

It worth adding that I'm not telling all of this things because I think
backward compatibility is a must: in fact I would also probably be fine
with a completely incompatible release (I will just tag the last
backward compatbile release for historical reference).

I'm just trying to transmit you as much knowledge as I can on the recent
historical issues of the project. I know I can leave this inheritance to
your careful hands.

>> - One is complete DNS support (requires changes in mailet api, in
>> smtpserver, in the spoolmanager and in the remote delivery) [trivia: I
>> joined JAMES mainly to add DSN support to it].
> 
> i don't understand why this would necessarily break
> storage/configuration compatibility

DSN requires many changes to mailet api and to core interfaces and
requires also to store much more informations. It also require a
different approach to spooling: as a consequence keeping the config.xml
backward compatible is almost impossible.

>> - probably there are many more I don't remember now.
>>
>> Btw, as you pointed out, maybe I'm too much worried about this as it
>> seems as no one have this issues in the roadmap anymore.
> 
> that's because i'm very carefully not to propose a roadmap ;-)
> 
> the road to 3.0 will lead to where ever people want it go

you can't understand how curious I am!!

>>> dubbing trunk 3.0 (rather than next-major) does not include or exclude
>>> a commitment to maintaining backwards compatibility. it consists of
>>> nothing more or less than deciding to adopt a new label. when someone
>>> wants to make a change that is not backwards compatible then this is
>>> when we should make a decision.
>> You "lead" this effort now, so let's play your game :-)
> 
> i'm not leading anything :-)

Don't tell me this, please! I've great expectations in your effort.

> i'm just doing what seems right to me

We all know you're pushing your own goals :-P :-P
And don't look around... you are alone, and you're leading! (at least
yourself: otherwise we are in trouble!)

> dubbing the trunk 3.0 seems a logical step right now so i proposed it
> 
> - robert

"but again truth be told, if you're looking for the guilty, you need
only look into a mirror" (cit. V)

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org