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? >> - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
