On 8/7/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> most people know that a long standing goal of mine has been to create >> independent lightweight protocol components (eg no avalon) that are >> used by JAMES but can also be used by other application. i think >> separate independent protocol components will have the following >> benefits: >> >> 1. the quantity of code on trunk will be singificantly reduced. this >> will result in a much quicker build, be more convenient to use in an >> IDE, be more comphensible to new developers and temporary issues with >> a single protocol will no long effect developers working on unrelated >> modules. >> 2. developers will be able to work on protocol components without >> needing to learn avalon. this would remove a reason why developers say >> they don't want to develop JAMES. >> 3. there is definite interest from other apache projects in these >> products. i believe that these components offer a new, untapped group >> of users and developers for JAMES. >> 4. independent versioning of the protocol components. this will allow >> the same code to be easily shared between different versions of JAMES. >> it will also reduce the amount of coordination required to create a >> new release. >> >> IMAP has now reached a stage where the tested coverage of the >> specification is now good. it's basically working. however, the >> implementation has a lot of room for improvement. in fact, i expect it >> to be completely rewritten. now is a very good time for IMAP to be >> moved out of server/trunk and into a separate independent protocol >> product. once this has been done, server can depend on a specific >> revision of the IMAP codebase that is know to be working reasonably >> well. this would open up milestones from trunk using a good IMAP >> version rather than whatever the current state of development is. >> >> i'd like to start making this change soon >> >> i'm a little unsure about the best option for arranging the >> directories. pushing server/trunk down a level to server/app sounds >> attractive to me ATM eg. >> >> server/app/trunk >> server/protocols/imap/trunk >> server/protocols/nntp/trunk (one day)... >> >> another option would be to add protocols at the top level. >> >> opinions? > > +1 for making protocols avalon-free (or better cornerstone and excalibur > free.. I don't care if you free it from avalon-framework or not). > > -0 for moving them out of trunk now. I would prefer if you start this > work inside trunk extracting the code to modules first and once we have > modules that satisfy us and are self contained we can start single votes > to extract them to separate products.
The easiest way to work on the simple protocols (not IMAP) would be to define a new peer module type 'protocols'. We could then start to enforce decoupling using the compiler. Robert > > If we choose this way we can define the right svn folder later. ATM I > would prefer to have a structure similar to mailet. So: > /james/protocols > /smtp > /branches > /tags > /trunk > /pop3 > /branches > /tags > /trunk > /imap > /branches > /tags > /trunk > /nntp > /branches > /tags > /trunk > /current > /smtp > /pop3 > /imap > /nntp > > IMHO moving code out from server now is premature. During the > refactoring you will probably identify some common code between the > protocol libraries and we'll have to define how to deal with the common > code once we extract them to a similar structure: we can ignore a lot of > issues if we start the work in trunk, instead. > > Stefano > > --------------------------------------------------------------------- > 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]
