james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Yoost <Jo...@jeld-wen.com>
Subject RE: IMAP Server Revisited
Date Wed, 17 Oct 2001 00:34:48 GMT

> >
> > I have started to rewrite the IMAP server portion.
> >
> > I want to take a different approach than was taken in the past.
> I think the IMAP server has been stagnant at "pre-alpha" (in CVS) for at
> least the last 4 months or so - if you're willing to take on the
> challenge,
> then any proposal will at least be considered. While not overly familiar
> with the current IMAP implementation, there's a significant amount of work
> in there already. I presume that there's a bunch of stuff that you'd be
> looking to include in a new proposal, anyway. (Surely most of the hard
> work,
> especially handling the IMAP wire protocol, has been done already. ;-)
	[John Yoost]  
	I'm not sure about the wire protocol, but as it is appropriate I
will refactor code that has been done to support such features as ACL
mailboxes as appropriate (when it gets into the base repository.  Like I
said there is a BOATLOAD of code to support IMAP's own repository as someone
else mentioned the UseIMAPRepository (or some such var).  I'll look into the
"wire protocol"

> Maybe detail a little more what you plan to rewrite, and what would be
> reused. I'm about to come into a bit more hacking time, and I'd like to be
> involved in this development. Charles was the author of most of the
> current
> code-base, and I'm sure he'll have some ideas as well.
	[John Yoost]  
	Basically I'm following the existing code and starting with 3 files.


	As I need the functionality of other files I will decide whether it
goes in the base repository code or IMAP code.  Most of the other code
supports the peculiarities of IMAP mailboxes, which I feel should be in the
repository code.  Maybe this would be a good division of labor for you to
work on the repository part and I stick to the IMAPServer part what do you

> >
> > I would like to include all the functionality up-to the point that I can
> > using the existing generic repository (file or DB).
> >
> > When I get to the point of adding functionality that is not currently
> > supported by the repository I will request (or add myself) this
> > functionality to the repository code.
> IMHO, reusing the MailRepository seems like a solid approach. Can you give
> us an idea of how much of IMAP is possible using the current
> MailRepository
> implementation, and what things you'd be looking to add?
	[John Yoost]  
	I will try to assess this as best I can.  I do know that logging in,
listing mailboxes, selecting a mailbox, creating a mailbox, deleteing a
mailbox, copying from one to another, and of course reading mail would all
be possible with the current repository. Remote mailboxes or accounts, ACL
mailboxes, and subscribing to a mailbox, would require some refactoring.

> Would it be possible, and maybe simpler, to adapt the current IMAP
> codebase
> to use the current Mail Repository implementation. Can you point out
> anything fundamental about the current implemenation that would prevent
> this?
	[John Yoost]  
	For someone who knows the current codebase that would be the route
to go.  But no one has stepped up to the plate to accept that challenge :)

	This is my suggestion as an alternative to that.  Also to make the
IMAP code more in line with POP3, and SMTP.

> At the same time, I'd love to get the IMAP-specific stuff out of the main
> MailServer block, if possible. I don't really like the current
> "useIMAPStorage" principle - I'd love to try to make that transparent to
> the
> MailServer. Again, I'm not sure of the reasons that this was designed this
> way, so maybe this is a pipe-dream.
	[John Yoost]  
	This is my EXACT POINT :)

> I'll have a gander at the code in the next few days. Please let me know
> where you are at, and a few more details about your proposed design.
	[John Yoost]  
	Let me know If you need more information on my proposed design than
	 -John Yoost 

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

View raw message