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: Mailets and dependencies (Was: [PLANNING] Road map)
Date Sun, 03 Feb 2008 08:33:03 GMT
On Feb 3, 2008 12:03 AM, Danny Angus <danny@apache.org> wrote:
> I did the "v3" stuff and the sandbox stuff isn't very different, look
> at it, I can do it all again.
> The problems are really only...
> 1/ some of the interfaces that you need to move to mailet aren't
> totally normalised, IOW they are a bit hacked to make them work in
> James not the way you would design them from scratch,

probably better not to move the interfaces but to create new ones in
new packages

> and
> 2/ RemoteDelivery is a total hack right now


> and needs a) a complete
> rethink and b) a fully featured implementation of javamail with
> callbacks (to Listeners messages) from events that occur after they
> have been queued, possibly upto to several days and several restarts
> after they enter the outgoing queue.

looks nasty and seems a bit beyond me at first sight but i'll take a
stab anyway. maybe this function would be better pushed into the
mailet engine (eg deliver("smtp://user@mail.example.org") using the
URL proposal). a pluggable extension point for SMTP transport would
allow an alternative commons mail based implementation.

but there's no need to move everything all at once. stefano has
identified contents for a viable decoupled standard mailet sub-project
which can be started right now. the security SMIME stuff is also
viable but would work best as a separate sub-project (the PGP/MIME
mailets from the branch would be merged in). should be easier to fix
the corner cases once we've moved the easy stuff out of trunk.

- robert

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

View raw message