You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2005/08/19 13:31:30 UTC
Top level blocks refactorings
I'm planning a few changes in the main blocks and cleaning the assembly.
Here are a few example:
1) Remove unused dependecy from the current assembly: e.g.
org.apache.james.services.MailStore from
SMTPServer/RemoteManager/POP3Server,
org.apache.james.services.JamesConnectionManager from James,
org.apache.avalon.cornerstone.services.threads.ThreadManager from
JamesSpoolManager.
2) Deprecate/Remove unused methods from common interfaces: e.g. MailServer
provides 4 sendMails methods but only 1 is used from SMTPHandler and
MessageProcessor. The other 3 methods are always accessed via the
MailetContext interface (provided by the same component: James).
3) Remove the inboundSpool concept from the MailStore by promoting the
"inbound" SpoolRepository to a toplevel block that James and
JamesSpoolManager will depend on. 2 advantages: possibility to implement
multiple spoolmanagers with multiple spoolrepositories, limit the
interdependencies of components (the Spoolmanager does not need the full
MailStore but only the inbound spoolrepository).
4) Promote MailetLoader and MatcherLoader to block components: this allow us
to make them easily configurable and allow to limit the knowledge needed by
the SpoolManager (the spoolmanager itself does not need the MailetContext
knowledge). To do that we need to change the Loaders to be Serviceable and
to remove the MailetContext parameter from the load calls.
5) More to come....
I would like to know if any committer is against this kind of changes.
The number 3, for example, will need minor config.xml changes (the inbound
spool conf moved outside the spoolmanager conf).
The others will be transparent for users that didn't change the assembly
(MOST users).
I will track every change with a JIRA issue and the consequent svn commit so
you can check my work.
Including internal "API" changes (as for number 2) is a point in favor of
3.0 instead 2.3.0 for the next release.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP - Re: Top level blocks refactorings
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I have been watching James's progress for
> the last 3 years now, hoping for IMAP
> support ( I can't use James without it )
> and this seems like the only way IMAP is
> going to ever get into main branch. IMAP
> support has been 'coming soon' for at
> least those 3 years I've known of James.
Exactly the same boat :).
> Currently, I am looking at pulling the
> IMAP code out of Foedus
> [ http://sourceforge.net/projects/foedus ]
> and maybe integrating with MINA and using
> that as a base for a simple IMAP only
> server. Alternatively, we can work
> together.
It seems hoever that Foedus is abandonware, and
the CVS was also not working.
> Having IMAP locked away in its own
> branch secludes the effort from the rest
> of the project and I think that's at
> least partly why it hasn't been done
> yet.
Totally agree.
> That, and the fact that there
> hasn't been an *authorative* detailed
> plan on how to get that subproject
> completed.
When users ask about such plans, the standard answer is to 'read the
mail archive' :). Clear sign that there's no *authorative* at all :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
IMAP - Re: Top level blocks refactorings
Posted by "Kervin L. Pierre" <ke...@adevsoft.com>.
Hello,
Along with the refactoring, can we begin
including tiny bits of IMAP support code
and marking those experiment, and turned
off by default?
I have been watching James's progress for
the last 3 years now, hoping for IMAP
support ( I can't use James without it )
and this seems like the only way IMAP is
going to ever get into main branch. IMAP
support has been 'coming soon' for at
least those 3 years I've known of James.
Currently, I am looking at pulling the
IMAP code out of Foedus
[ http://sourceforge.net/projects/foedus ]
and maybe integrating with MINA and using
that as a base for a simple IMAP only
server. Alternatively, we can work
together.
Having IMAP locked away in its own
branch secludes the effort from the rest
of the project and I think that's at
least partly why it hasn't been done
yet. That, and the fact that there
hasn't been an *authorative* detailed
plan on how to get that subproject
completed.
Regards,
Kervin
Stefano Bagnara wrote:
> I'm planning a few changes in the main blocks and cleaning the assembly.
>
> Here are a few example:
>
> 1) Remove unused dependecy from the current assembly: e.g.
> org.apache.james.services.MailStore from
> SMTPServer/RemoteManager/POP3Server,
> org.apache.james.services.JamesConnectionManager from James,
> org.apache.avalon.cornerstone.services.threads.ThreadManager from
> JamesSpoolManager.
>
> 2) Deprecate/Remove unused methods from common interfaces: e.g. MailServer
> provides 4 sendMails methods but only 1 is used from SMTPHandler and
> MessageProcessor. The other 3 methods are always accessed via the
> MailetContext interface (provided by the same component: James).
>
> 3) Remove the inboundSpool concept from the MailStore by promoting the
> "inbound" SpoolRepository to a toplevel block that James and
> JamesSpoolManager will depend on. 2 advantages: possibility to implement
> multiple spoolmanagers with multiple spoolrepositories, limit the
> interdependencies of components (the Spoolmanager does not need the full
> MailStore but only the inbound spoolrepository).
>
> 4) Promote MailetLoader and MatcherLoader to block components: this allow us
> to make them easily configurable and allow to limit the knowledge needed by
> the SpoolManager (the spoolmanager itself does not need the MailetContext
> knowledge). To do that we need to change the Loaders to be Serviceable and
> to remove the MailetContext parameter from the load calls.
>
> 5) More to come....
>
> I would like to know if any committer is against this kind of changes.
>
> The number 3, for example, will need minor config.xml changes (the inbound
> spool conf moved outside the spoolmanager conf).
>
> The others will be transparent for users that didn't change the assembly
> (MOST users).
>
> I will track every change with a JIRA issue and the consequent svn commit so
> you can check my work.
>
> Including internal "API" changes (as for number 2) is a point in favor of
> 3.0 instead 2.3.0 for the next release.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Top level blocks refactorings
Posted by Stefano Bagnara <ap...@bago.org>.
> > I will track every change with a JIRA issue and the consequent svn
> > commit so you can check my work.
>
> You don't need to use JIRA if you post messages to this list.
> Personally I'd rather read mail from you than from JIRA, and
> the list is the appropriate place for discussing
> status/progress and making decisions. It is archived too.
I am for task/feature tracking in JIRA because we get free
roadmap/status/changelog.
And more, when you look at a commit comment with a JIRA issue in the log you
have better reference.
Soon I will post a list of open "issues/tasks" that I would like to close
soon and need your votes/opinions.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Top level blocks refactorings
Posted by Danny Angus <da...@gmail.com>.
> I will track every change with a JIRA issue and the consequent svn commit so
> you can check my work.
You don't need to use JIRA if you post messages to this list.
Personally I'd rather read mail from you than from JIRA, and the list
is the appropriate place for discussing status/progress and making
decisions. It is archived too.
> Including internal "API" changes (as for number 2) is a point in favor of
> 3.0 instead 2.3.0 for the next release.
+1
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org