On Tue, Aug 5, 2008 at 9:08 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: >> >> On 8/3/08, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
