Robert Burrell Donkin ha scritto:
On 8/3/08, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
