You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/08/05 22:06:10 UTC
[PROPOSAL] Separate Protocol Products
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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Bernd Fondermann <be...@googlemail.com>.
On Thu, Aug 7, 2008 at 19:53, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Thu, Aug 7, 2008 at 12:06 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>
> <snip>
>
>> Moving protocol related stuff into server-independent components will
>> soon raise technical questions:
>>
>> 1. What _is_ the 'protocol' domain?
>> 2. How does this domain interface with the rest of the system it is deployed in?
>>
>> 'Protocol' for me connotes closely with 'connection', 'paser',
>> 'command' and 'command handling', and not so closely with 'session',
>> 'session state' and 'interfacing backend services'. At some point we'd
>> have to draw a line and define what's inside the protocol domain and
>> how this interfaces with the rest.
>
> IMHO each protocol needs to define it's own boundaries. IMAP is a
> session based stateful protocol with very peculiar backend
> requirements. JAMES server would then weave each protocol into a
> cohesive system
>
>> I tried to do this in a layered way (onion) in Vysper, not sure how
>> much the architectural patterns from there can be applied to James.
>> Another interesting aspect for me is that POP3 is somehow a functional
>> subset of IMAP. How do we do this right without duplication?
>
> POP3 and IMAP are similar conceptually but each specification
> approaches the problem quite differently. sharing behaviours
> (interfaces) is inappropriate in this situation. POP3 only requires a
> very shallow knowledge of the mail. IMAP requires that a mail is
> completely decomposable into it's constituate parts. POP3 can be used
> with a wide varieties of backends. IMAP requires a specialised backend
> with associated overhead.
>
> i think that the level of commality is much lower, at the data store
> level. i'm very interested in mime-based meta-data aware mail stores
> (note mail, not email). for example, i think that it'd cool to be
> able to have JAMES Fetch an RSS feed, filter using SIEVE and then
> expose through IMAP, POP3 or NNTP.
Interesting. I am excited where this is leading us.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 7, 2008 at 12:06 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
<snip>
> Moving protocol related stuff into server-independent components will
> soon raise technical questions:
>
> 1. What _is_ the 'protocol' domain?
> 2. How does this domain interface with the rest of the system it is deployed in?
>
> 'Protocol' for me connotes closely with 'connection', 'paser',
> 'command' and 'command handling', and not so closely with 'session',
> 'session state' and 'interfacing backend services'. At some point we'd
> have to draw a line and define what's inside the protocol domain and
> how this interfaces with the rest.
IMHO each protocol needs to define it's own boundaries. IMAP is a
session based stateful protocol with very peculiar backend
requirements. JAMES server would then weave each protocol into a
cohesive system
> I tried to do this in a layered way (onion) in Vysper, not sure how
> much the architectural patterns from there can be applied to James.
> Another interesting aspect for me is that POP3 is somehow a functional
> subset of IMAP. How do we do this right without duplication?
POP3 and IMAP are similar conceptually but each specification
approaches the problem quite differently. sharing behaviours
(interfaces) is inappropriate in this situation. POP3 only requires a
very shallow knowledge of the mail. IMAP requires that a mail is
completely decomposable into it's constituate parts. POP3 can be used
with a wide varieties of backends. IMAP requires a specialised backend
with associated overhead.
i think that the level of commality is much lower, at the data store
level. i'm very interested in mime-based meta-data aware mail stores
(note mail, not email). for example, i think that it'd cool to be
able to have JAMES Fetch an RSS feed, filter using SIEVE and then
expose through IMAP, POP3 or NNTP.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Aug 5, 2008 at 22:06, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> 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.
+1, this general direction has my full support!
Moving protocol related stuff into server-independent components will
soon raise technical questions:
1. What _is_ the 'protocol' domain?
2. How does this domain interface with the rest of the system it is deployed in?
'Protocol' for me connotes closely with 'connection', 'paser',
'command' and 'command handling', and not so closely with 'session',
'session state' and 'interfacing backend services'. At some point we'd
have to draw a line and define what's inside the protocol domain and
how this interfaces with the rest.
I tried to do this in a layered way (onion) in Vysper, not sure how
much the architectural patterns from there can be applied to James.
Another interesting aspect for me is that POP3 is somehow a functional
subset of IMAP. How do we do this right without duplication?
I am looking forward to disussing this in dedicated threads as it
becomes neccessary.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 8/7/08, Stefano Bagnara <ap...@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
Re: [PROPOSAL] Separate Protocol Products
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 8/7/08, Stefano Bagnara <ap...@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:
>>> [...]
>>> 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.
Works for me (I didn't analyze this issue in depth yet).
If working in trunk make it harder then we can move out. But I'll prefer
to stay in trunk as long as it is possible.
e.g: AFAIK refactoring between separated projects take much more time
than refactoring on a single project within Eclipse, mainly because of
svn integration not being able to make "svn cp" to span projects
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 8/7/08, Stefano Bagnara <ap...@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
Re: [PROPOSAL] Separate Protocol Products
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Thu, Aug 7, 2008 at 2:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
>> -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.
>
> IMAP is multi-module so this would not be possible. the mailbox code
> is useful only for IMAP is ending up tightly coupled to that
> particular protocol. moving IMAP gives a big initial pay: removal of
> half-a-dozen or so modules plus cutting the compile-test cycle by one
> third.
>
> for NNTP, STMP, POP3 and so, my expectation is that the work could be
> done on trunk.
I'm fine with this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 7, 2008 at 2:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
> -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.
IMAP is multi-module so this would not be possible. the mailbox code
is useful only for IMAP is ending up tightly coupled to that
particular protocol. moving IMAP gives a big initial pay: removal of
half-a-dozen or so modules plus cutting the compile-test cycle by one
third.
for NNTP, STMP, POP3 and so, my expectation is that the work could be
done on trunk.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery test issue (Was: [PROPOSAL] Separate Protocol
Products)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Aug 8, 2008 at 9:17 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Thu, Aug 7, 2008 at 2:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> 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.
>>> please be aware that the issue with remote delivery test makes it
>>> impossible for me to develop on trunk any longer
>> Robert.. I don't really know what to do with the remote delivery test issue.
>>
>> You know better than me how you prefer to deal with it, so people go ahead
>> and remove the test if this create issues to you.
>>
>> I don't have any magical solution to this. The test randomly fails.. I don't
>> know why and I've been able to reproduce the problem once in hundreds of
>> runs in my machine. If you can give me access to an environment where the
>> issues show up more often I can try investigating on this a bit more...
>
> it fails most times on my machine
>
> maybe i'll try to hook up on irc tommorrow...
I think I solved the "random" issue on testMulti. I committed a fix
today, let's see.
No news from me instead of the serialization issue. I don't plan to do
further work on that one unless there are news, so maybe we should
simply remove the test if this keeps randomly failing on your machine.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RemoteDelivery test issue (Was: [PROPOSAL] Separate Protocol Products)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Aug 8, 2008 at 9:17 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Thu, Aug 7, 2008 at 2:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> 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.
>>
>> please be aware that the issue with remote delivery test makes it
>> impossible for me to develop on trunk any longer
>
> Robert.. I don't really know what to do with the remote delivery test issue.
>
> You know better than me how you prefer to deal with it, so people go ahead
> and remove the test if this create issues to you.
>
> I don't have any magical solution to this. The test randomly fails.. I don't
> know why and I've been able to reproduce the problem once in hundreds of
> runs in my machine. If you can give me access to an environment where the
> issues show up more often I can try investigating on this a bit more...
it fails most times on my machine
maybe i'll try to hook up on irc tommorrow...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RemoteDelivery test issue (Was: [PROPOSAL] Separate Protocol Products)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Thu, Aug 7, 2008 at 2:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> 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.
>
> please be aware that the issue with remote delivery test makes it
> impossible for me to develop on trunk any longer
Robert.. I don't really know what to do with the remote delivery test issue.
You know better than me how you prefer to deal with it, so people go
ahead and remove the test if this create issues to you.
I don't have any magical solution to this. The test randomly fails.. I
don't know why and I've been able to reproduce the problem once in
hundreds of runs in my machine. If you can give me access to an
environment where the issues show up more often I can try investigating
on this a bit more...
If you want me to remove the test and create a JIRA with this, just ask
and I'll do, but really, feel free to do what accomodate your needs
about this.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 7, 2008 at 2:55 PM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> 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
same here
> 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.
please be aware that the issue with remote delivery test makes it
impossible for me to develop on trunk any longer
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] Separate Protocol Products
Posted by Stefano Bagnara <ap...@bago.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org