+1 Thanks, Robert. Great post!
Bernd On 8/1/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On 7/31/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > Robert Burrell Donkin ha scritto: > > > On 7/31/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
