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: [modules] Backends
Date Sat, 02 Feb 2008 18:39:46 GMT
Robert Burrell Donkin ha scritto:
> i now wonder whether it might be better to aggregate backend classes
> according to the technologies they use. so (for example) any backend
> code that uses torque would be in a torque-backend module, any code
> that uses avalon to store data in a avalon-backend module and so on.
> any backend implementations that just use java would be moved into a
> base-backend module.

This could not be so easy.

Our torque function also depends on avalon services.

Our JDBC based repositories also depends on avalon because they supports 
both db and dbfile "protocols".

BTW I think we should at least (as a first step) separate backend code 
from other core library classes. Core-library contains too much 
unrelated code ATM.

I run a few grep to see what modules/code import each class/package in 
core-library and here are some considerations:

org.apache.james.security.*
- they are only used by spoolmanager-function, and only by smime mailets 
(org.apache.james.transport.mailets.smime.*).

org.apache.james.management.*
- this package is imported by remotemanager-function and by core-library 
itself (org.apache.james.services). There is a cyclic dependency issue 
between org.apache.james.management and org.apache.james.service that 
should be resolved as a priority.

org.apache.james.domain.*
- backend implementation: contains XML and JDBC version (and common 
abstract code). no other module depends on this.

org.apache.james.mailboxmanager.*
- imap-mailbox-processor-function, imapserver-function, 
torque-mailboxmanager-function depends on this.
- sieve mailets in "spoolmanager-function" depends on this (I would like 
to see this dependency removed)
- phoenix-deployment depends on this because of 
PhoenixImapProcessorFactory and TorqueMailboxManagerFactory
I think the whole mailboxmanager package could be moved to a different 
library module as no other core-library class depends on it, but I'm not 
sure the current api-library-function-deployment layers let us to do 
this right now, unless we move some class down to an api module.

org.apache.james.core.*
- this is a problematic package. This contains some core James object 
like MailImpl/MimeMessageWrapper/MailHeaders but also contains common 
components for current protocol functions 
(AbstractJamesHandler/AbstractJamesService).

org.apache.james.util.watchdog.*
org.apache.james.util.connection.*
- they are related to AbstractJamesHandler/AbstractJamesService.

org.apache.james.util.junkscore.*
- is only used by smtpserver-function (we might move this in the 
function itself)

org.apache.james.util.Lock
- belongs to the repository logic

org.apache.james.util.mail.mdn.*
- only used by sieve mailets. This is almost standalone utility code, 
maybe we should move this where we move sieve mailets, or give them a 
custom module (this depends on how we'll reorganize mailets). It imports 
  org.apache.james.util.mail.MimeMultipartReport and the 
org.apache.james.util.mail.handlers.* classes.

org.apache.james.util.mail.dsn.DSNStatus
- utility class used by smtpserver and by the DSNBounce mailet. To make 
DSNBounce a non-James-specific mailet we have to move this somewhere 
else, but where??

org.apache.james.util.mail.MimeMultipartReport
org.apache.james.util.mail.handlers.*
- they are used by DNSBounce and by the mdn code. Something along the 
line of the DSNStatus destiny.

org.apache.james.util.JDBCBayesianAnalyzer
org.apache.james.util.BayesianAnalyzer
- they deserve their own package. And maybe they belong to the backend 
stuff.

org.apache.james.util.urirbl.*
- this is smtpserver-function stuff. maybe we can move this package 
there, for the moment.

org.apache.james.util.POP3BeforeSMTPHelper
- this is "weird" because it links pop3function to the smtpfunction 
(smtpserver.core.POP3BeforeSMTPHandler, pop3server.PassCmdHandler). It 
is an smtp specific feature)

org.apache.james.util.DotStuffingInputStream
org.apache.james.util.SchedulerNotifyInputStream
org.apache.james.util.CharTerminatedInputStream
org.apache.james.util.ExtraDotOutputStream
org.apache.james.util.InternetPrintWriter
org.apache.james.util.TimeConverter
org.apache.james.util.Base64
org.apache.james.util.CRLFTerminatedReader
org.apache.james.util.SqlResources
- utility classes. maybe we should remove oro dependency from 
timeconverter. Some of them are specific to our 
AbstractJamesHandler/AbstractJamesService stuff)

org.apache.james.util.MatcherInverter
- belongs to the util.mailet package. should we move it there?

org.apache.james.util.NetMatcher
- used by many mailets and by some smtpserver code. it depends on the 
DNSServer, and I wonder if it should better depends on a modified Mailet 
API (including the getByName method).

org.apache.james.util.dbcp.JdbcDataSource
- this is avalon/excalibur function code. it implements the 
org.apache.avalon.excalibur.datasource.DataSourceComponent interface and 
is only used via that service. belongs to the backend.

org.apache.james.util.io.*
- maybe we should remove this in favor of commons-io library. This is 
pure java, no deps, utility code for IO. I guess this was once avalon 
code, that has been integrated in james because of avalon death but also 
found his way in jakarta commons.

org.apache.james.util.mailet.*
- this code is only used by some of our mailets.

org.apache.james.context.*
- this is a function code. It is the Avalon/Phoenix implementation of 
our FileSystem service. Should be moved away from this module (phoenix 
deployment?)

org.apache.james.services.*
- ehm.. time is running out and this package is tricky.. so let's delay 
it for a while ;-)

HTH,
Stefano

PS: maybe all of this message is OT, and the subject should be "what do 
we have in core-library?" ;-)


---------------------------------------------------------------------
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