[mailets] SieveToMultiMailbox and MailboxDelivery

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

(bit of a brain dump but seemed more useful to present neonate ideas
for improvement rather than wait until they're fully grown)
(hopefully people will jump in and correct any mistakes i make)

1. MailboxDelivery depends on SieveToMultiMailbox. SieveToMultiMailbox
depends on mailboxmanager et al. mailboxmanager is tightly coupled to
IMAP. MailboxDelivery and SieveToMultiMailbox live in spoolmanager.
this smell a little bad to me.

2. not alot depends on MailboxDelivery. AFACT composes
UsersRepositoryAliasingForwarding (to perform mapping of user alias
etc) and SieveToMultiMailbox. so it must live in spoolmanager and not
with the other mailets, as - in turn - must SieveToMultiMailbox. i've
been wondering whether MailboxDelivery is worthwhile.

3. there are a couple of cases where compile-time combinations are
used and cause coupling issues. i've been wondering whether this is
the best approach. i wonder whether this kind of combination might be
more generally useful and so worth abstracting. this would help with
the coupling.

4. i keep wondering whether the UsersRepositoryAliasingForwarding
coupling is trying to tell me something. i wonder whether separate
processors for the actual delivery might be a more poweful concept.

5. Sieve is increasingly being employed as a general DSL in a similar
way to the mailets and matchers. mailboxmanager is a big, ugly API. i
think that SieveToMultiMailbox. would be more useful if it had lighter
coupling.

6. SieveToMultiMailbox is coupled to the JAMES file system as the only
way to load it's scripts. i would like to store scripts in a JCR.
perhaps it would be better to factor this out somehow.

7. IMHO SieveToMultiMailbox is just about big enough for an
independent existance as a micro-library. this would mean factoring
out the dependencies into interfaces. this would mean more advanced
configuration.

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] SieveToMultiMailbox and MailboxDelivery

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

On Tue, Sep 9, 2008 at 10:41 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:

<snip>

>> 2. not alot depends on MailboxDelivery. AFACT composes
>> UsersRepositoryAliasingForwarding (to perform mapping of user alias
>> etc) and SieveToMultiMailbox. so it must live in spoolmanager and not
>> with the other mailets, as - in turn - must SieveToMultiMailbox. i've
>> been wondering whether MailboxDelivery is worthwhile.
>
> IMHO it can be removed. the LocalDelivery split into
> UsersRepositoryAliasingForwarding+ToMultiRepository was done to separate
> concerns and the LocalDelivery has been retained because of backward
> compatibility. No need to have composite mailets otherwise.

ok

>> 3. there are a couple of cases where compile-time combinations are
>> used and cause coupling issues. i've been wondering whether this is
>> the best approach. i wonder whether this kind of combination might be
>> more generally useful and so worth abstracting. this would help with
>> the coupling.
>
> Can you make the "couple of cases" explicit?

LoaclDelivery and MailetDelivery (but this could probably be deleted)

> The "LocalDelivery" binding to James.java should be removed as soon as we
> remove the deprecated "store" method from the mailet api...

yes

i wanted to observe that composition of mailets would not require
actual coupling between the mailets

>> 4. i keep wondering whether the UsersRepositoryAliasingForwarding
>> coupling is trying to tell me something. i wonder whether separate
>> processors for the actual delivery might be a more poweful concept.
>
> As a side note, the move from one processor to another is a performance
> bottleneck in james now. The first optimization I do in high traffic james
> server is to use a single processor for the main route (local+remote
> delivery) and then move things to other processor only when i can't do
> differently. But this is probably an issue in the
> spoolmanager/stateawareprocessorlist stuff.

James does a *lot* of byte copying. i think the vast majority of this
should be unnecessary. i would like to see the next generation of
mailet API move away from DOM based representations (such as
javax.mail) towards a MIME-document plus meta-data paradigm. i think
that this should reduce the amount of copying necessary.

>> 5. Sieve is increasingly being employed as a general DSL in a similar
>> way to the mailets and matchers. mailboxmanager is a big, ugly API. i
>> think that SieveToMultiMailbox. would be more useful if it had lighter
>> coupling.
>>
>> 6. SieveToMultiMailbox is coupled to the JAMES file system as the only
>> way to load it's scripts. i would like to store scripts in a JCR.
>> perhaps it would be better to factor this out somehow.
>
> Loading additional configurations is something that could be provided by the
> container. We could add a SPI for this too (and JAMES will use the
> AvalonFileSystem to implement it). (in fact FileSystem could be a SPI).
> I think we have other mailets having this configuration issue.

IMHO FileSystem is not a good general API. i would like to see
something simpler without a coupling to file. something more like

public InputStream get(String url) throws IOException;
public String[] getMembers(String url) throws IOException;

would be more generally useful

>> 7. IMHO SieveToMultiMailbox is just about big enough for an
>> independent existance as a micro-library. this would mean factoring
>> out the dependencies into interfaces. this would mean more advanced
>> configuration.
>
> A micro library for a single class? You already know I don't like this...
> Maybe you are talking about the whole sieve package. In this case it could
> work.

yes - it was the complete package i meant not the class

> Could this become a "mailet" module in the jsieve project?

+1

- robert

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

Re: [mailets] SieveToMultiMailbox and MailboxDelivery

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

Robert Burrell Donkin ha scritto:
> (bit of a brain dump but seemed more useful to present neonate ideas
> for improvement rather than wait until they're fully grown)
> (hopefully people will jump in and correct any mistakes i make)
> 
> 1. MailboxDelivery depends on SieveToMultiMailbox. SieveToMultiMailbox
> depends on mailboxmanager et al. mailboxmanager is tightly coupled to
> IMAP. MailboxDelivery and SieveToMultiMailbox live in spoolmanager.
> this smell a little bad to me.

I agree.

> 2. not alot depends on MailboxDelivery. AFACT composes
> UsersRepositoryAliasingForwarding (to perform mapping of user alias
> etc) and SieveToMultiMailbox. so it must live in spoolmanager and not
> with the other mailets, as - in turn - must SieveToMultiMailbox. i've
> been wondering whether MailboxDelivery is worthwhile.

IMHO it can be removed. the LocalDelivery split into 
UsersRepositoryAliasingForwarding+ToMultiRepository was done to separate 
concerns and the LocalDelivery has been retained because of backward 
compatibility. No need to have composite mailets otherwise.

> 3. there are a couple of cases where compile-time combinations are
> used and cause coupling issues. i've been wondering whether this is
> the best approach. i wonder whether this kind of combination might be
> more generally useful and so worth abstracting. this would help with
> the coupling.

Can you make the "couple of cases" explicit?
The "LocalDelivery" binding to James.java should be removed as soon as 
we remove the deprecated "store" method from the mailet api...

> 4. i keep wondering whether the UsersRepositoryAliasingForwarding
> coupling is trying to tell me something. i wonder whether separate
> processors for the actual delivery might be a more poweful concept.

As a side note, the move from one processor to another is a performance 
bottleneck in james now. The first optimization I do in high traffic 
james server is to use a single processor for the main route 
(local+remote delivery) and then move things to other processor only 
when i can't do differently. But this is probably an issue in the 
spoolmanager/stateawareprocessorlist stuff.

> 5. Sieve is increasingly being employed as a general DSL in a similar
> way to the mailets and matchers. mailboxmanager is a big, ugly API. i
> think that SieveToMultiMailbox. would be more useful if it had lighter
> coupling.
> 
> 6. SieveToMultiMailbox is coupled to the JAMES file system as the only
> way to load it's scripts. i would like to store scripts in a JCR.
> perhaps it would be better to factor this out somehow.

Loading additional configurations is something that could be provided by 
the container. We could add a SPI for this too (and JAMES will use the 
AvalonFileSystem to implement it). (in fact FileSystem could be a SPI).
I think we have other mailets having this configuration issue.

> 7. IMHO SieveToMultiMailbox is just about big enough for an
> independent existance as a micro-library. this would mean factoring
> out the dependencies into interfaces. this would mean more advanced
> configuration.

A micro library for a single class? You already know I don't like 
this... Maybe you are talking about the whole sieve package. In this 
case it could work.

Could this become a "mailet" module in the jsieve project?

Stefano

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