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: [PROPOSAL] Separate Protocol Products
Date Fri, 08 Aug 2008 06:51:59 GMT
On 8/7/08, Stefano Bagnara <apache@bago.org> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

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