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 Adam Fowler <Ad...@ideagen.co.uk> on 2004/05/21 10:05:27 UTC

IMAP2, Maildir, JNDI/LDAP progress update...

Hello all,

I have now successfully managed to get Alex's Maildir code working with
James. Or at least I think it's working! My system uses IMAP so I need to
test it through that, unfortunately the IMAP2 proposal code uses an in
memory store instead of using the configured Maildir inboxRepository.
There's even a comment in the code saying this needs doing.

So last night I turned a couple of the IMAP2 classes into
AbstractJamesService's and am currently modifying their code to look up a
MailStore. There seems to be an additional ImapStore interface. I'm hoping
to create a generalised wrapper ImapStore which can use MailStores. If I can
do this then users can just plug and play with different stores/protocols
just as they should be able to </controversy>.

So in future the ImapServer service will use the configured ImapHost service
which will use the configured ImapStore service (my DefaultImapStore
implementation) which in turn will use the configured MailStore
implementation (using MaildirMailRepository). Confused yet!?! ;o)

Once I've got IMAP2 and Maildir working I'll test it with LDAP. If these
work then I'll create individual patches for the IMAP2 work, Maildir work
and Alex's LDAP. God knows how you guys are gonna merge the james-config.xml
for these, but hey ho. 8o) *coff* glad I don't have to *coff*

I'll go into JIRA now and add the "add IMAP2 support for other MailStores",
"add Maildir support" and "Add LDAP users store support" issues.

Hopefully I'll have some patches done by mid/end next week.

Regards,

Adam.
This email and any files attached is intended for the addressee only and may contain information that is confidential and/or legally privileged. Unauthorised use is strictly prohibited and may be unlawful. If you are not the addressee, you should not read, copy, disclose or otherwise use this message, including any attachment, except for the purpose of delivery to the addressee.

We make every effort to keep our network free from viruses. However, you do need to verify this e-mail and any attachments to it to be virus free as we can take no responsibility for any computer virus which might be transferred by way of this e-mail.

Scanning of this message and addition of this footer is performed by SurfControl E-mail Filter software in conjunction with virus detection software.

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


RE: IMAP2, Maildir, JNDI/LDAP progress update...

Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm very leery of distracting a push to get IMAP implemented to
> another extended design thread.

As long as we can keep it isolated, sure.  I just want us to have the
flexiblity to look at our design decisions coherently down the road.

> > I would also like to see the system support better optimization [...]
> I think all this entails adding a move (or copy?) method to a mail
> store.  Where would you put this functionality?

Oh, I think it does need to be in the store.  Probably a public API, and
then some means for the store(s) to decide if it/they can do the
optimization.

	--- Noel


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


Re: IMAP2, Maildir, JNDI/LDAP progress update...

Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>defining a standard API for IMAP mail store is great.
> 
> Revising an API for mail stores, period.  Right now we don't have one to
> delete, for example, when a user is no longer served.  However, I am not
> entirely sure where best to do some of this.  For example, if JNDI were
> mandatory for User Repositories, then the folder hierarchy could be
> represented in the DIT, rather than the message store.

I'm very leery of distracting a push to get IMAP implemented to another 
extended design thread.

Adam, I would suggest you spend some time reading over the very 
extensive discussions last summer (?) about user and mail repositories. 
  A sample of some of the threads:

JavaMail Store/Folder for IMAP store
http://marc.theaimsgroup.com/?l=james-dev&m=105730144906290&w=2

General redesign on user and mail stores
http://marc.theaimsgroup.com/?l=james-dev&m=105154760130220&w=2

Repositories (design suggestion)
http://marc.theaimsgroup.com/?l=james-dev&m=105171385227991&w=2

I had this grandiose (probably unachievable as it assumes much of the 
above is done) vision of a virtual folder system, which I think is how 
Exchange works.

http://marc.theaimsgroup.com/?l=james-dev&m=105173109117897&w=2

In the end, we came away with general goals, but no real plan, and 
nothing concrete.  The general goals were:
- a single mail store support spooling (though spooling logic 
separatable), pop mailboxes, nntp mail stores, and imap mailboxes.
- separate user auth (username/password) from user repository (mailbox 
location, forwarding, quotas, etc...)
- rely on JNDI over Avalon lookups or mailet context methods to get to 
mail and user stores.

I would prefer you weren't too encumbered by this, but they are some 
nice goals. ;)

> I would also like to see the system support better optimization so that once
> a message has been brought into the system, we don't need to copy it when
> the movement is between compatible locations.  dbfile is currently the only
> one that comes close (mostly works).

I think all this entails adding a move (or copy?) method to a mail 
store.  Where would you put this functionality?

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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


RE: IMAP2, Maildir, JNDI/LDAP progress update...

Posted by "Noel J. Bergman" <no...@devtech.com>.
> defining a standard API for IMAP mail store is great.

Revising an API for mail stores, period.  Right now we don't have one to
delete, for example, when a user is no longer served.  However, I am not
entirely sure where best to do some of this.  For example, if JNDI were
mandatory for User Repositories, then the folder hierarchy could be
represented in the DIT, rather than the message store.

I would also like to see the system support better optimization so that once
a message has been brought into the system, we don't need to copy it when
the movement is between compatible locations.  dbfile is currently the only
one that comes close (mostly works).

	--- Noel


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


Re: IMAP2, Maildir, JNDI/LDAP progress update...

Posted by Serge Knystautas <se...@lokitech.com>.
Adam Fowler wrote:
> I have now successfully managed to get Alex's Maildir code working with
> James. Or at least I think it's working! My system uses IMAP so I need to
> test it through that, unfortunately the IMAP2 proposal code uses an in
> memory store instead of using the configured Maildir inboxRepository.
> There's even a comment in the code saying this needs doing.

Adam,

I still have to resolve the licensing for Alex's maildir.  Irrespective 
of this, defining a standard API for IMAP mail store is great.

> So last night I turned a couple of the IMAP2 classes into
> AbstractJamesService's and am currently modifying their code to look up a
> MailStore. There seems to be an additional ImapStore interface. I'm hoping
> to create a generalised wrapper ImapStore which can use MailStores. If I can
> do this then users can just plug and play with different stores/protocols
> just as they should be able to </controversy>.
> 
> So in future the ImapServer service will use the configured ImapHost service
> which will use the configured ImapStore service (my DefaultImapStore
> implementation) which in turn will use the configured MailStore
> implementation (using MaildirMailRepository). Confused yet!?! ;o)

Not yet.  Sounds good.

> Hopefully I'll have some patches done by mid/end next week.

Sounds great.  Hopefully we've got the 2.2.0 release out by then.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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