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 Tue, 05 Aug 2008 18:40:02 GMT
On Tue, Aug 5, 2008 at 9:08 AM, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On 8/3/08, Stefano Bagnara <apache@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


Mime
View raw message