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: [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)
Date Mon, 04 Aug 2008 20:40:24 GMT
On 8/3/08, Stefano Bagnara <apache@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

> 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

View raw message