On Thu, Apr 24, 2008 at 8:23 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
>
> >
> > >  Either you remove all the modules that will depened on IMAP-Mailbox or
> you
> > >
> > > will need to release IMAP-Mailbox BEFORE being able to release JAMES
> server.
> > >
> >
> >
> > i plan to remove all modules that depend on IMAP-mailbox other than
> > the deployment ones. if IMAP is not released when the time comes for a
> > server release then the jars can be removed from stage during the
> > final push.
> >
>  [...]
>
>
> >
> > >  Sorry but I don't get it: "james-server-imapmailbox-library" is
> currently
> > > *3* classes for a total of 33KB of java sources: does this really
> require an
> > > *external* module ??? Maybe instead you are talking about more modules?
> In
> > > this case can you make an explicit list?
> > >
> >
> > i propose the complete removal of all code related to mailbox and IMAP
> > (old and new). lots of modules and half of core.
> >
>
>  So your "IMAP/Mailbox" in the title was referring to "all the IMAP API,
> libraries and functions modules, including the mailbox ones." and not the
> "imapmailbox-library" module as I took it. Is this correct?
>
>  This means you would split "JAMES Server" into 2 projects by moving the
> following modules to a new multimodule project depending on some of the
> JAMES Server modules:
>  imap-mailbox-processor-function
>  imapmailbox-library
>  torque-mailboxmanager-function
>  imapserver-function
>  imap-codec-library
>  imap-command-library
>  imap-api
>  experimental-seda-imap-function
>
>  Is this correct?

more or less

plus the mailbox API from core

> In this case sorry for the previous reply, as I totally
> got it wrong ;-) In this case I have to think a bit more about it...

of course: i wanted to announce the idea so that people can get used to it

>  Furthermore the new project would depend on JAMES Server and not viceversa,
> right?

no

with a little refactoring i think i can break the essential
co-dependency into a very small number of interface classes. i propose
to introduce a minimal SPI to hold these interfaces. some glue code
will be required in deployment coupled to both IMAP and JAMES but the
functions in the server and IMAP will be coupled only by a minimal
interface.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to