On 1/8/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Freitag, den 05.01.2007, 19:56 +0100 schrieb Joachim Draeger:
> Am Freitag, den 05.01.2007, 09:19 +0000 schrieb Danny Angus:
>
> > > The best way would be a native, logical, hierarchical mailbox access
> > > through the Mailet API.
> >
> > If you would like to expand on this idea I'd be interested in seeing
> > what it looks like when applied to sandbox/mailet-refactorings/. If
> > you want to have a go yourself please do, otherwise talk about it and
> > I'll do something.
>
> I have probably some time tomorrow. I hope this also brings some drive
> in general MailboxManager API development. :-)
I made a few more thoughts and came to the conclusion that it IMO makes
no sense to copy the MailboxManager interfaces to Mailet API in the
sandbox.
At first it should reach maturity. Then we could split up a subset for
the Mailet API. This all can be done in trunk.
What you are probably interested in is an example for the use case
"MailboxManager usage inside a Mailet". This can also be done in trunk.
So I'm going to write a MailboxManager LocalDelivery and
LocalSieveDelivery.
could you explain just a little more about these?
i've been trying to understand the design of MailboxManager for a
while now without success. there are various methods to get various
flavours of session. i'm a little confused about why a general API
needs protocol specific methods. (i'm sure there are reasons but i
don't see them ATM.)
i've been trying to think about email from a different perspective
current solutions tend to be constrained by the central position of
mailboxes in their design. i think it's powerful to consider an email
as an URI: a identified resource. mailboxes are then just become
collections of resources but this seems really similar to other
searches. perhaps the inner workings of an advanced server need not
care whether the search is for mail in mailbox 'james', for mails from
'server-dev@james.apache.org' or tagged with 'james'.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
