[server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)

[Stefano Bagnara <ap...@bago.org>]

Stefano Bagnara ha scritto:
> Hi all,
> 
> After I moved tests in the right places (excluding IMAP), I'd like to 
> sort out a better structure for our modules.
> IMHO we have some modules that is not appropriate (domain-api, as an 
> example, contains unrelated interfaces, does not need to exist) and we 
> have the core-module that should be splitted into multiple modules.
> 
> The first thing I'd like to do is to create a "server-library" (or maybe 
> a listener-library / daemon-library) including code that is used by 
> services listening (pop3server, smtpserver, imapserver, nntpserver, 
> remotemanager).

While a wait an answer I'm working on this new module and I have questions.

1) any preference about the name? (it will include common code for 
cornerstone/excalibur based tcp listening services)

2) InternetPrintWriter is used both by code that will belong to the new 
module and by code used by other classes in core-library: I see we 
already have another copy in imap-codec-library. Should I make another 
copy or maybe it's better to have an "util-api" module (the name is 
weird, but this is the "workaround" for introducing an utility module in 
the current ant build)? I don't like code duplication so I would prefer 
to have the "api name" workaround or to introduce multiple dependencies 
levels in our build (maven does not have this limit, so ant build should 
be updated someway)...

3) I identified this classes as candidates to be part of this new module:
util.connection.*
services.JamesConnectionManager
core.AbstractJamesService
core.AbstractJamesHandler
util.watchdog.*
core.CopyInputStream
core.SplitOutputStream
util.CRLFTerminatedReader
util.InternetPrintWriter (* see #2)

4) util.connection.* simply contains implementations for 
services.JamesConnectionManager and they names are directly referred in 
assembly.xml . IMHO they should be moved to a different package (they 
are not utilities, they are implementations of a service!). Maybe they 
should be moved and then we can create a compatibility-function module 
(or maybe put them in the phoenix-deployment, so that we don't bring 
this stuff to the spring deployment too) with classes in the old package 
simply extending the one in the new package. Opinions?

5) Most classes I listed in #3 should be moved to better packages to not 
overlap with already existing packages. Excluding 
services.JamesConnectionManager and the util.connection package I 
already discussed in #4 they are only used in james code and I think it 
is unlikely they are widely used by JAMES users/developers, so I propose 
to repackage them without creating a compatibility layer (we can create 
it in case someone will complain). I would use:
"something.connman" instead of util.connection
"something.watchdog" instead of util.watchdog
"services.JamesConnectionManager" unchanged (ATM, for compatibility 
reasons, and maybe moved to an API module later, but this is 
cornerstone/excalibur specific)
"something" for every other class from core and util listed in #3.
Where "something" should be the same name we choose for the library name 
(something-library, so, something could be "daemon", "listener", 
"handler", or any other idea you may propose....). ATM I'm slightly for 
something composite like "avalon-handler-library" and the "something" 
package could be "handler.avalon"

I think the answer to this use case will allow me to proceed with other 
simpler choices, too.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Tue, Aug 5, 2008 at 9:08 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On 8/3/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Stefano Bagnara ha scritto:
>>>>> The first thing I'd like to do is to create a "server-library" (or maybe
>>>>> a listener-library / daemon-library) including code that is used by
>>>>> services listening (pop3server, smtpserver, imapserver, nntpserver,
>>>>> remotemanager).
>>>> While a wait an answer I'm working on this new module and I have
>>>> questions.
>>>>
>>>> 1) any preference about the name? (it will include common code for
>>>> cornerstone/excalibur based tcp listening services)
>>> Server is overused. I've always thought of this code as the socket
>>> handling layer so perhaps that might be a direction towards a more
>>> descriptive name.
>> avalon-sockets-library ?
> 
> works for me

Done

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)

[Robert Burrell Donkin <ro...@gmail.com>]

On Tue, Aug 5, 2008 at 9:08 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On 8/3/08, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Stefano Bagnara ha scritto:

<snip>

>>>> The first thing I'd like to do is to create a "server-library" (or maybe
>>>> a listener-library / daemon-library) including code that is used by
>>>> services listening (pop3server, smtpserver, imapserver, nntpserver,
>>>> remotemanager).
>>>
>>> While a wait an answer I'm working on this new module and I have
>>> questions.
>>>
>>> 1) any preference about the name? (it will include common code for
>>> cornerstone/excalibur based tcp listening services)
>>
>> Server is overused. I've always thought of this code as the socket
>> handling layer so perhaps that might be a direction towards a more
>> descriptive name.
>
> avalon-sockets-library ?

works for me

<snip>

>>> 3) I identified this classes as candidates to be part of this new module:
>>> util.connection.*
>>> services.JamesConnectionManager
>>> core.AbstractJamesService
>>> core.AbstractJamesHandler
>>> util.watchdog.*
>>> core.CopyInputStream
>>> core.SplitOutputStream
>>> util.CRLFTerminatedReader
>>> util.InternetPrintWriter (* see #2)
>>
>> yes: this is the basic JAMES socket handling code
>>
>> one of the structure changes i really want to make sometime very soon
>> is to factor out the coupling between the socket handling and the
>> protocols. i would like to replace the current inheritance with
>> delegation. this would allow the protocols to be used independently of
>> the socket handling layer.
>
> +1 we already discussed it, we did some tests about this in an "handlerapi
> branch" wrt smtpserver, but you will try a different path starting from your
> imap work and we'll see if this will work for other protocols, too. The
> critical issues are in commands that requires changes in the way the
> protocol works, e.g: STARTTLS and SMTP's DATA, I'm very interested in the
> solution you will find because I felt my solution was not elegant at all.

IMHO don't need an elegant solution, just an effective one

for example, switching the boolean (close or open) to a int would be good enough

> Another thing was the push based model (to support mina) vs the current
> inputstream approach for input data.

IMHO no need to adopt the same interface

>>> 4) util.connection.* simply contains implementations for
>>> services.JamesConnectionManager and they names are directly referred in
>>> assembly.xml . IMHO they should be moved to a different package (they
>>> are not utilities, they are implementations of a service!). Maybe they
>>> should be moved and then we can create a compatibility-function module
>>> (or maybe put them in the phoenix-deployment, so that we don't bring
>>> this stuff to the spring deployment too) with classes in the old package
>>> simply extending the one in the new package. Opinions?
>>
>> i agree that they are mispackaged
>>
>> the systems of API, library, function is just the rules for the
>> modularisation game. we could choose new ones if they don't suit.
>
> Maybe we can add another type of module at the same level of api, named
>  "-common" or "-util" so that this kind of module is usable by libraries and
> have no dependencies (like apis). From ant this would be the same of the api
> modules, simply with a different extension. Simple to introduce in ant and
> give us a bit more flexibility, WDYT?

IMHO this flexibility is usually unhelpful since it's just an excuse
to avoid sorting out the coupling issues. if necessary, i would prefer
a module called dump (or something like that) that libraries and up
could depend on.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On 8/3/08, Stefano Bagnara <ap...@bago.org> wrote:
>> Stefano Bagnara ha scritto:
>>> Hi all,
>>>
>>> After I moved tests in the right places (excluding IMAP), I'd like to
>>> sort out a better structure for our modules.
> 
> Yeh - this has also been on my mind
> 
>>> IMHO we have some modules that is not appropriate (domain-api, as an
>>> example, contains unrelated interfaces, does not need to exist) and we
>>> have the core-module that should be splitted into multiple modules.
> 
> The initial modularisation was always intended to be provisional

I know, that's why I'd like to complete this provisional stuff.

>>> The first thing I'd like to do is to create a "server-library" (or maybe
>>> a listener-library / daemon-library) including code that is used by
>>> services listening (pop3server, smtpserver, imapserver, nntpserver,
>>> remotemanager).
>> While a wait an answer I'm working on this new module and I have questions.
>>
>> 1) any preference about the name? (it will include common code for cornerstone/excalibur based tcp listening services)
> 
> Server is overused. I've always thought of this code as the socket
> handling layer so perhaps that might be a direction towards a more
> descriptive name.

avalon-sockets-library ?

>> 2) InternetPrintWriter is used both by code that will belong to the new
>> module and by code used by other classes in core-library: I see we
>> already have another copy in imap-codec-library. Should I make another
>> copy or maybe it's better to have an "util-api" module (the name is
>> weird, but this is the "workaround" for introducing an utility module in
>> the current ant build)? I don't like code duplication so I would prefer
>> to have the "api name" workaround or to introduce multiple dependencies
>> levels in our build (maven does not have this limit, so ant build should
>> be updated someway)...
> 
> This isn't not an essential limitation of Ant: it's a self imposed
> discipline. It might be time to reconsider the structure.

Sure, this was obvious to me. It's a limit of our current build and I 
never thought it was a limit of ant itself. I also undestand that is a 
limit that has been introduced with judgement, and I am simply trying to 
move forward without having to rewrite the build system because I don't 
want to work on ant too much and I knew you don't have much time for 
this currently.

> one of the major issues with JAMES in terms of modularity is that too
> much code is lazily coupled to utilities. with a little bit of effort
> a lot, these utilities could have been moved into commons, or just
> forked.
> 
>> 3) I identified this classes as candidates to be part of this new module:
>> util.connection.*
>> services.JamesConnectionManager
>> core.AbstractJamesService
>> core.AbstractJamesHandler
>> util.watchdog.*
>> core.CopyInputStream
>> core.SplitOutputStream
>> util.CRLFTerminatedReader
>> util.InternetPrintWriter (* see #2)
> 
> yes: this is the basic JAMES socket handling code
> 
> one of the structure changes i really want to make sometime very soon
> is to factor out the coupling between the socket handling and the
> protocols. i would like to replace the current inheritance with
> delegation. this would allow the protocols to be used independently of
> the socket handling layer.

+1 we already discussed it, we did some tests about this in an 
"handlerapi branch" wrt smtpserver, but you will try a different path 
starting from your imap work and we'll see if this will work for other 
protocols, too. The critical issues are in commands that requires 
changes in the way the protocol works, e.g: STARTTLS and SMTP's DATA, 
I'm very interested in the solution you will find because I felt my 
solution was not elegant at all. Another thing was the push based model 
(to support mina) vs the current inputstream approach for input data.

>> 4) util.connection.* simply contains implementations for
>> services.JamesConnectionManager and they names are directly referred in
>> assembly.xml . IMHO they should be moved to a different package (they
>> are not utilities, they are implementations of a service!). Maybe they
>> should be moved and then we can create a compatibility-function module
>> (or maybe put them in the phoenix-deployment, so that we don't bring
>> this stuff to the spring deployment too) with classes in the old package
>> simply extending the one in the new package. Opinions?
> 
> i agree that they are mispackaged
> 
> the systems of API, library, function is just the rules for the
> modularisation game. we could choose new ones if they don't suit.

Maybe we can add another type of module at the same level of api, named 
  "-common" or "-util" so that this kind of module is usable by 
libraries and have no dependencies (like apis). From ant this would be 
the same of the api modules, simply with a different extension. Simple 
to introduce in ant and give us a bit more flexibility, WDYT?

>> 5) Most classes I listed in #3 should be moved to better packages to not
>> overlap with already existing packages. Excluding
>> services.JamesConnectionManager and the util.connection package I
>> already discussed in #4 they are only used in james code and I think it
>> is unlikely they are widely used by JAMES users/developers, so I propose
>> to repackage them without creating a compatibility layer (we can create
>> it in case someone will complain). I would use:
>> "something.connman" instead of util.connection
>> "something.watchdog" instead of util.watchdog
>> "services.JamesConnectionManager" unchanged (ATM, for compatibility
>> reasons, and maybe moved to an API module later, but this is
>> cornerstone/excalibur specific)
>> "something" for every other class from core and util listed in #3.
>> Where "something" should be the same name we choose for the library name
>> (something-library, so, something could be "daemon", "listener",
>> "handler", or any other idea you may propose....). ATM I'm slightly for
>> something composite like "avalon-handler-library" and the "something"
>> package could be "handler.avalon"
> 
> i think that improved packaging naming would be a great benefit. it
> opens up improved assembly technologies such as OSGI.

Good!

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)

[Robert Burrell Donkin <ro...@gmail.com>]

On 8/3/08, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>> Hi all,
>>
>> After I moved tests in the right places (excluding IMAP), I'd like to
>> sort out a better structure for our modules.

Yeh - this has also been on my mind

>> IMHO we have some modules that is not appropriate (domain-api, as an
>> example, contains unrelated interfaces, does not need to exist) and we
>> have the core-module that should be splitted into multiple modules.

The initial modularisation was always intended to be provisional

>> The first thing I'd like to do is to create a "server-library" (or maybe
>> a listener-library / daemon-library) including code that is used by
>> services listening (pop3server, smtpserver, imapserver, nntpserver,
>> remotemanager).
>
> While a wait an answer I'm working on this new module and I have questions.
>
> 1) any preference about the name? (it will include common code for cornerstone/excalibur based tcp listening services)

Server is overused. I've always thought of this code as the socket
handling layer so perhaps that might be a direction towards a more
descriptive name.

> 2) InternetPrintWriter is used both by code that will belong to the new
> module and by code used by other classes in core-library: I see we
> already have another copy in imap-codec-library. Should I make another
> copy or maybe it's better to have an "util-api" module (the name is
> weird, but this is the "workaround" for introducing an utility module in
> the current ant build)? I don't like code duplication so I would prefer
> to have the "api name" workaround or to introduce multiple dependencies
> levels in our build (maven does not have this limit, so ant build should
> be updated someway)...

This isn't not an essential limitation of Ant: it's a self imposed
discipline. It might be time to reconsider the structure.

one of the major issues with JAMES in terms of modularity is that too
much code is lazily coupled to utilities. with a little bit of effort
a lot, these utilities could have been moved into commons, or just
forked.

> 3) I identified this classes as candidates to be part of this new module:
> util.connection.*
> services.JamesConnectionManager
> core.AbstractJamesService
> core.AbstractJamesHandler
> util.watchdog.*
> core.CopyInputStream
> core.SplitOutputStream
> util.CRLFTerminatedReader
> util.InternetPrintWriter (* see #2)

yes: this is the basic JAMES socket handling code

one of the structure changes i really want to make sometime very soon
is to factor out the coupling between the socket handling and the
protocols. i would like to replace the current inheritance with
delegation. this would allow the protocols to be used independently of
the socket handling layer.

> 4) util.connection.* simply contains implementations for
> services.JamesConnectionManager and they names are directly referred in
> assembly.xml . IMHO they should be moved to a different package (they
> are not utilities, they are implementations of a service!). Maybe they
> should be moved and then we can create a compatibility-function module
> (or maybe put them in the phoenix-deployment, so that we don't bring
> this stuff to the spring deployment too) with classes in the old package
> simply extending the one in the new package. Opinions?

i agree that they are mispackaged

the systems of API, library, function is just the rules for the
modularisation game. we could choose new ones if they don't suit.

> 5) Most classes I listed in #3 should be moved to better packages to not
> overlap with already existing packages. Excluding
> services.JamesConnectionManager and the util.connection package I
> already discussed in #4 they are only used in james code and I think it
> is unlikely they are widely used by JAMES users/developers, so I propose
> to repackage them without creating a compatibility layer (we can create
> it in case someone will complain). I would use:
> "something.connman" instead of util.connection
> "something.watchdog" instead of util.watchdog
> "services.JamesConnectionManager" unchanged (ATM, for compatibility
> reasons, and maybe moved to an API module later, but this is
> cornerstone/excalibur specific)
> "something" for every other class from core and util listed in #3.
> Where "something" should be the same name we choose for the library name
> (something-library, so, something could be "daemon", "listener",
> "handler", or any other idea you may propose....). ATM I'm slightly for
> something composite like "avalon-handler-library" and the "something"
> package could be "handler.avalon"

i think that improved packaging naming would be a great benefit. it
opens up improved assembly technologies such as OSGI.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org