james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [server.trunk] extract "handler" stuff from core-module (Was: modules/package refactoring)
Date Tue, 05 Aug 2008 08:08:14 GMT
Robert Burrell Donkin ha scritto:
> 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

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.



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

View raw message