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.
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]
