[mailets] New Modules for SIEVE and listmanager [WAS Mailets and dependencies (Was: [PLANNING] Road map)]

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, Feb 2, 2008 at 5:51 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:

<snip>

>  > i think that it would be a good plan to pull out those mailets which
>  > are conceptually independent into separate a subproject (standard
>  > mailets, say)
>
>  I did some homework...

<snip>

>  Then we have mailets depending on avalon configuration, on james
> UsersRepositories and MailRepositories and more.

yes

but as a first step, it would be good to move them out of spoolmanager
and into separete modules. in particular, sieve belongs with
IMAP/mailbox and listmanager would be better as an independent
endeavor.

opinions?

- robert

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

Re: [mailets] New Modules for SIEVE and listmanager [WAS Mailets and dependencies (Was: [PLANNING] Road map)]

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> On Sat, Feb 2, 2008 at 5:51 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>  Then we have mailets depending on avalon configuration, on james
>> UsersRepositories and MailRepositories and more.
> 
> yes
> 
> but as a first step, it would be good to move them out of spoolmanager
> and into separete modules. in particular, sieve belongs with
> IMAP/mailbox and listmanager would be better as an independent
> endeavor.
> 
> opinions?

ATM I would leave everything depending on Mail/Spool/Users Repositories 
where it is. IMO JAMES needs refactoring there, so moving that code 
around would simply make it more difficult to having it fixed later.

We often discussed about introducing repositories in Mailet APIs, we 
also more often discussed that James needs better/different interfaces 
for Mail/Spool repositories. We also discussed that usersRepository are 
currently sharing "authentication", "user-properties" and 
"user-preferences" roles and we don't like this too much. Let's not 
write this interfaces in stone by having them to be the glue between 
multiple modules/libraries.

As usual this is a -0 and not a -1.

I am +0.5 for splitting the org.apache.james.transport package content 
from its mailet/matchers subpackages. They are not dependent on each 
other so they should not be nested as package (but fixing this would 
require breaking backward compatibility) and may belong to 2 different 
james-server modules. Maybe moving matcher/mailets packages to a 
"mailets-function" while leaving transport in "spoolmanager-function" 
would be fine ATM.

Stefano


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