james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: Roadmap? Or maybe not... [WAS Re: [VOTE] next-major from trunk will be 3.0]
Date Wed, 01 Aug 2007 08:04:26 GMT
On 7/31/07, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 7/31/07, Stefano Bagnara <apache@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


Mime
View raw message