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 Zoe <zo...@mac.com> on 2003/11/09 22:36:02 UTC

IMAP implementation questions

Hello,

I have been perusing James current draft IMAP implementation and I have 
a couple of newbie questions :)

- Does the current IMAP implementation uses something akin to 
javax.mail.Authenticator to authenticate a request? In 
org.apache.james.imapserver, there are references to 
org.apache.mailet.User and org.apache.mailet.UsersRepository. Is it how 
the authentication is handled? I cannot quiet track it down. Where is 
that done? How do I introduce my own Authenticator?

- Looking at the different commands found in 
org.apache.james.imapserver.commands, I can see that they work in term 
of something called org.apache.james.imapserver.store.ImapStore. But 
ImapStore, while similar, doesn't seem to be compatible with 
javax.mail.Store. Is that correct? In the same vain, ImapMailbox looks 
similar to javax.mail.Folder, but it has an incompatible API. And 
ImapMessage looks like javax.mail.Message, but isn't quite one. Any 
reasons for such similar but not quite same API? Did I overlooked 
something? Is James API as used by the IMAP implementation somehow 
compatible with the JavaMail API as far as the basic Store, Folder and 
Message goes? Could the IMAP implementation work in terms of JavaMail's 
Store, Folder and Message? And more generally in term of javax.mail?

- Looking at org.apache.james.imapserver.commands.FetchCommand, I can 
see that there is a couple of classes to encapsulate a request 
(FetchRequest, FetchElement, etc). But looking at the JavaMail API, 
there seems to be a very similar package to handle a query: 
javax.mail.search. Are the two compatible? Could the FetchCommand 
produce a SearchTerm to query a Folder by using its search() method?

- In org.apache.james.imapserver.store, there is something called 
MailboxListener. In JavaMail, there is something called 
javax.mail.event.FolderListener with looks similar. There are also 
several other interfaces and events with looks relevant. Are those two 
notification mechanism compatible? Can I use javax.mail.event to notify 
the IMAP implementation of changes in the underlying Store? Would those 
event be propagated to the client?

Thanks in advance for any insights :)

Cheers,

Z.

-- 
http://zoe.nu/


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


Re: IMAP implementation questions

Posted by Zoe <zo...@mac.com>.
Hi Danny,

On Nov 10, 2003, Danny Angus wrote:

> Zoe, (Beware, long answer!)

Thanks for the explanations :)

> Ist point.. James IMAP component is very much alpha status *still* .

Oh, well... that would make only three incomplete IMAP implementations 
I know of: James, JimapD and Foedus. Do I see a trend here ;)

> [snip rational]
>
> So.. What is the answer for ZOE...
>
>  Well my impression of James is that I think that it would be 
> foolhardy to
> take James' alpha IMAP and try to rewrite it with no reference to 
> James,
> Avalon or Mailet and I think it would be exceedingly tortuous (but not
> necessarily impossible) to implement an IMAP server using JavaMail.

I'm going to find out very soon as a solution stumbled upon me: a 
lightweight, IMAP SDK build in terms of the JavaMail API. With such a 
toolkit, one only needs to provide its own implementation of a 
javax.mail.Store to the SDK. The SDK handles all the IMAP protocol 
minutia and interact with the underlying data through the Store, Folder 
and Message API. All this in a small package and no other dependencies 
than JavaMail :)

> It might be worth looking at Avalon Phoenix or Merlin and see whether 
> you
> could implement (or integrate) a container within ZOE to allow you to 
> run
> IMAP.

Well... this is what I would like to avoid in the first place.

Thanks for the walkthrough in any case :) Hopefully I will not need to 
"highjack" James IMAP implementation to turn it into something it was 
not mean to be.

That said... I still think there would be some values in repackaging 
James different protocol stacks to make them more accessible to third 
parties. Something to think about perhaps.

Cheers,

Z.

-- 
http://zoe.nu/


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


RE: IMAP implementation questions

Posted by Jason Webb <jw...@inovem.com>.
Hi Zoe (if that's your name and not your project's :) If it is,
apologies)
The IMAP part of James is not in step with the current James code for
one important reason:
You cannot persist messages in an IMAP store. This is because the
current implmentation of IMAP takes messages (from SMTP) and stores them
in memory. The reasons for this are historical and I am working out how
to merge the current James code and the IMAP proposal together to form a
unified (and working whole).
I am working from the IMAP2 proposal. I believe both the IMAP and IMAP2
proposals are IMAP4v1 compliant.
Authenication is handled via org.apache.mailet.UsersRepository IIRC. To
change authenticator (to use a DB for example) check the code that does
the JDBC user repository as it's a bit more obvious. You would then need
to implement an Avalon component that did your required auth. and get
James to use that instead of db: or file:.

As far as the IMAP commands go. No idea at all. Sorry :(

-- Jason

> -----Original Message-----
> From: Zoe [mailto:zoe_info@mac.com] 
> Sent: 09 November 2003 21:36
> To: server-dev@james.apache.org
> Subject: IMAP implementation questions
> 
> 
> Hello,
> 
> I have been perusing James current draft IMAP implementation 
> and I have 
> a couple of newbie questions :)
> 
> - Does the current IMAP implementation uses something akin to 
> javax.mail.Authenticator to authenticate a request? In 
> org.apache.james.imapserver, there are references to 
> org.apache.mailet.User and org.apache.mailet.UsersRepository. 
> Is it how 
> the authentication is handled? I cannot quiet track it down. Where is 
> that done? How do I introduce my own Authenticator?
> 
> - Looking at the different commands found in 
> org.apache.james.imapserver.commands, I can see that they 
> work in term 
> of something called org.apache.james.imapserver.store.ImapStore. But 
> ImapStore, while similar, doesn't seem to be compatible with 
> javax.mail.Store. Is that correct? In the same vain, 
> ImapMailbox looks 
> similar to javax.mail.Folder, but it has an incompatible API. And 
> ImapMessage looks like javax.mail.Message, but isn't quite one. Any 
> reasons for such similar but not quite same API? Did I overlooked 
> something? Is James API as used by the IMAP implementation somehow 
> compatible with the JavaMail API as far as the basic Store, 
> Folder and 
> Message goes? Could the IMAP implementation work in terms of 
> JavaMail's 
> Store, Folder and Message? And more generally in term of javax.mail?
> 
> - Looking at org.apache.james.imapserver.commands.FetchCommand, I can 
> see that there is a couple of classes to encapsulate a request 
> (FetchRequest, FetchElement, etc). But looking at the JavaMail API, 
> there seems to be a very similar package to handle a query: 
> javax.mail.search. Are the two compatible? Could the FetchCommand 
> produce a SearchTerm to query a Folder by using its search() method?
> 
> - In org.apache.james.imapserver.store, there is something called 
> MailboxListener. In JavaMail, there is something called 
> javax.mail.event.FolderListener with looks similar. There are also 
> several other interfaces and events with looks relevant. Are 
> those two 
> notification mechanism compatible? Can I use javax.mail.event 
> to notify 
> the IMAP implementation of changes in the underlying Store? 
> Would those 
> event be propagated to the client?
> 
> Thanks in advance for any insights :)
> 
> Cheers,
> 
> Z.
> 
> -- 
> http://zoe.nu/
> 
> 
> ---------------------------------------------------------------------
> 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