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 Edward Flick <ed...@cdf-imaging.com> on 2003/09/03 21:45:17 UTC
IMAP Development Pointers
I was just wondering what needs to be done as far as getting IMAP support to
at least a beta phase. I am willing to code some for it, but a quick ramp
up on the situation would be nice if anyone would care to provide it.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP Development Pointers
Posted by tuckun <tu...@mail.diligence.com>.
Just out of curiosity, is there anything wrong with just using the
Take a look at dbmail (http://www.dbmail.org/) They have an imap
implementation on top of a database.
Is there IMAP code in the CVS? I didn't see it last time I looked.
PS.
If I was to take some GPLed C code (from dbmail) and tried to shoehorn
into James would this cause some sort of a licensing conflict. IT would
be a radical rewrite so that C code would be more like a guide or a howto.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP Development Pointers
Posted by Jim Wright <ji...@paneris.org>.
Hi Edward,
Edward Flick wrote:
>Just out of curiosity, is there anything wrong with just using the
>filesystem? Folders work wonders :-P. And sets of enumerated files for
>messages would be nice, easy, and quick to implement, and I guess some quick
>and easy link file for common boxes between accounts. What do you think?
>Of course this is before really looking through much code. But I like to
>get started on the right foot.
>
>
I have University of Washington IMAP on my Linux machine
and use an experimental format mx which is as you describe.
To quote the docs:
. mx This is an experimental format, and may be removed in a future
release. ...
[snip]
mx is somewhat inefficient; the entire directory must be read
and each file stat()'d. We found it intolerable for a
moderate sized mailbox (2000 messages) and have more or less
abandoned it.
[snip]
There's a general reason why file/message formats are a bad idea.
Just about every filesystem in existance serializes file creation and
deletions because these manipulate the free space map. This turns out
to be an enormous problem when you start creating/deleting more than a
few messages per second; you spend all your time thrashing in the
filesystem.
It is also extremely slow to do a text search through a
file/message format mailbox. All of those open()s and close()s really
add up to major filesystem thrashing.
I was not completely convinced by this. File system devices are getting
faster for a start.
Jim Wright
--
Recently completed - Child Brain Injury Trust Admin System
http://cbitdemo.paneris.org/
Urgently seeking paid work
Java, Linux, XML and much more.
http://be.webz.cz/
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP Development Pointers
Posted by Kris Bravo <kr...@corridor-software.us>.
Ed and Noel,
You can still consider me in for working on parts of the IMAP
implementation. I've been buried on a political tracking tool since last
poking around in the existing experimental code. The only other
experience I have with James beyond just using the server was to have
wrote my own EJB user repository to tie it into some other services. So
be gentle.
I'll get a fresh copy of the codebase from cvs tonight so I can see what
the heck you guys are talking about :) My original need for IMAP was to
tie into Squirrel Mail and give myself web access, but I worked around
it using jwebmail with the Bibop theme. Squirrel still looks like a
better choice to me, so the need is still there (only works with IMAP,
not POP3).
-Bravo
Noel J. Bergman wrote:
>Ed,
>
>Other people who have expressed interest in contributing to IMAP are
>(alphabetically):
>
> Kris Bravo
> Joe Cheng
> Maxwell Grender-Jones
> Nawwar Kasrawi
> Christian Myrvold
> Sascha Kulawik
> Kenny Smith
> Peter Svensson
>
>And that is just this year. All it takes to do it is to do it. With Jason
>contributing help on the store changes, if just a few people would take the
>reins on IMAP, it could really pick up. Hopefully Darrell could spare some
>time to bring people up to speed.
>
>Jason, if the change to "user.folder" is made, then we can use, but don't
>even need maildir, since the string is just a simple key. The hierarchy is
>a bit of fiction at the moment. I mention this because IMAP may benefit
>from having mail attributes, which are supported by the existing JDBC and
>file-system repository formats, but not by the new mbox and planned maildir
>repositories.
>
>So I believe that:
>
> file://var/mail/inboxes/ --> file://var/mail/inboxes/noel (inbox)
> file://var/mail/inboxes/ --> file://var/mail/inboxes/noel.aFolder
> db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel (inbox)
> db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel.aFolder
> mbox:///var/mail/ --> mbox:///var/mail/noel (inbox)
> mbox:///var/mail/ --> mbox:///var/mail/noel.aFolder
>
>Is that what you had in mind? I am not showing a change. I am showing how
>the current code would map the repository name, which is the portion
>appended on the right-hand side.
>
> --- Noel
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Is it not possible to keep a copy of the message on the server, or am I
misunderstanding what you mean by that.
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Friday, September 05, 2003 9:02 AM
To: 'James Developers List'
Subject: RE: IMAP Development Pointers
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 05 September 2003 15:02
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> That sounds fine to me. I mainly just want something
> working. What locking mechanism are you using with the mbox
> store, though? And how does it recover from power loss
> mid-spool? Just wondering.
The mbox spool uses dot-locking using files (not symlinks) to deal with
other processes accessing the mbox
Because of the way the James POP server works the worst that's likely to
happen is you get some (or all) of the messages twice. This is because
the POP handler deletes all the messages in a store in one go, rather
than a message at a time
>
> Ed
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Friday, September 05, 2003 3:23 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
>
>
<snip'd>
---------------------------------------------------------------------
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
Re: IMAP Development Pointers
Posted by Serge Knystautas <se...@lokitech.com>.
Kervin L. Pierre wrote:
> I believe that it is up to the client that is making those mailboxes. I
> use mozilla, and it creates those mailboxes under the INBOX mailbox.
>
> Here is some hierarchy of multiple mailboxes on my cyrus imap server
>
> ...
> user.kervin.Trash@kervin.net (\HasNoChildren)
> user.kervin.lists.james@blueprintinc.com (\HasNoChildren)
> user.kervin.lists@blueprintinc.com (\HasChildren)
> user.kervin@blueprintinc.com (\HasChildren)
> user.kervin@kervin.net (\HasChildren)
> ...
>
> Cyrus appends the user's domain name at the end of every mailbox for
> virtual server support.
Mozilla (for me) keeps INBOX separate, so I think the server determines
the folder structure.
--
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: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Kervin, just so you know that was Surge that wrote that. I wrote a response
which your post gives a perfect example to.
-----Original Message-----
From: Kervin L. Pierre [mailto:kervin@blueprintinc.com]
Sent: Friday, September 05, 2003 4:03 PM
To: James Developers List
Subject: Re: IMAP Development Pointers
Edward Flick wrote:
>
> In fact I was under the impression that INBOX is a reserved folder name,
True
> that it should always be there, and you are not allowed to create
> subfolders of it.
You are allowed.
>
> Anyway, the mail servers I am familiar with do place INBOX at the same
> left as Sent, Draft, and whatever other top level folders you might have
> rather than nesting everything under INBOX.
I believe that it is up to the client that is making those mailboxes. I
use mozilla, and it creates those mailboxes under the INBOX mailbox.
Here is some hierarchy of multiple mailboxes on my cyrus imap server
...
user.kervin.Trash@kervin.net (\HasNoChildren)
user.kervin.lists.james@blueprintinc.com (\HasNoChildren)
user.kervin.lists@blueprintinc.com (\HasChildren)
user.kervin@blueprintinc.com (\HasChildren)
user.kervin@kervin.net (\HasChildren)
...
Cyrus appends the user's domain name at the end of every mailbox for
virtual server support.
--
------------------------------------------------
Kervin Pierre
http://kervin.net/
kervin@blueprintinc.com
kervin@kervin.net
kpierre@fit.edu
---------------------------------------------------------------------
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
Re: IMAP Development Pointers
Posted by "Kervin L. Pierre" <ke...@blueprintinc.com>.
Edward Flick wrote:
>
> In fact I was under the impression that INBOX is a reserved folder name,
True
> that it should always be there, and you are not allowed to create
> subfolders of it.
You are allowed.
>
> Anyway, the mail servers I am familiar with do place INBOX at the same
> left as Sent, Draft, and whatever other top level folders you might have
> rather than nesting everything under INBOX.
I believe that it is up to the client that is making those mailboxes. I
use mozilla, and it creates those mailboxes under the INBOX mailbox.
Here is some hierarchy of multiple mailboxes on my cyrus imap server
...
user.kervin.Trash@kervin.net (\HasNoChildren)
user.kervin.lists.james@blueprintinc.com (\HasNoChildren)
user.kervin.lists@blueprintinc.com (\HasChildren)
user.kervin@blueprintinc.com (\HasChildren)
user.kervin@kervin.net (\HasChildren)
...
Cyrus appends the user's domain name at the end of every mailbox for
virtual server support.
--
------------------------------------------------
Kervin Pierre
http://kervin.net/
kervin@blueprintinc.com
kervin@kervin.net
kpierre@fit.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
unintended bonus, kewl
-----Original Message-----
From: Noel J. Bergman [mailto:noel@devtech.com]
Sent: Friday, September 05, 2003 2:57 PM
To: James Developers List
Subject: RE: IMAP Development Pointers
> in the IMAP4rev1 RFC, it shows instances of there being subfolders of
> INBOX, but INBOX is special in that it always exists, and when you do
> a rename of INBOX it just create a new folder and moves the contents
> of INBOX into it.
And re-recreates a new INBOX?
So if I have INBOX and rename it to INCOMING, it will rename INBOX to
INCOMING, and create a new folder called INBOX?
The current code will automatically create a missing repository, so it
should handle that just fine.
--- Noel
---------------------------------------------------------------------
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
RE: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
> in the IMAP4rev1 RFC, it shows instances of there being subfolders of
> INBOX, but INBOX is special in that it always exists, and when you do
> a rename of INBOX it just create a new folder and moves the contents
> of INBOX into it.
And re-recreates a new INBOX?
So if I have INBOX and rename it to INCOMING, it will rename INBOX to
INCOMING, and create a new folder called INBOX?
The current code will automatically create a missing repository, so it
should handle that just fine.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Well, in the IMAP4rev1 RFC, it shows instances of there being subfolders of
INBOX, but INBOX is special in that it always exists, and when you do a
rename of INBOX it just create a new folder and moves the contents of INBOX
into it.
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Friday, September 05, 2003 1:20 PM
To: James Developers List
Subject: Re: IMAP Development Pointers
Noel J. Bergman wrote:
> There is no hierarchy. They are just names. The hierarchy is a fiction.
> Just adopt a convention for how IMAP wants to map the names into a
> hierarchy.
>
> No one said that user.folder should be interpreted as a child of the
inbox.
> It could be a peer. In terms of the actual storage mapping, they ARE
peers;
> there is no hierachy. You might decide to map inbox children (internally)
> as user.INBOX.folder. But I do not want to change the basic inbox name
from
> user to user.INBOX because of existing repositories.
In fact I was under the impression that INBOX is a reserved folder name,
that it should always be there, and you are not allowed to create
subfolders of it. I don't think many enforce the no-subfolder of INBOX
rule, and I may just be remembering wrong.
Anyway, the mail servers I am familiar with do place INBOX at the same
left as Sent, Draft, and whatever other top level folders you might have
rather than nesting everything under INBOX. As these IMAP stores are
developers and we look to share POP3 and IMAP stores, the POP3 handler
will just know to always user user.INBOX.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
You might ask Darrell. I haven't spent much time looking at either
proposal.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=5591
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Danny Angus <da...@apache.org>.
I'd suggest that its up to you,
Both are proposals, meaning that it would take a vote of comitters to move
iether back into james' tree, and consequently into releases.
Therefore logic says you are entitled to work on either, I suspect, but
can't remember, that IMAP2 is newer and has been patched more often and more
recently.
d.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 09 September 2003 10:50
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> I hate to use discussion forum techniques on a mail list...
> *bump* :)
>
> I'm still not sure which IMAP implementation to use
>
> > -----Original Message-----
> > From: Jason Webb [mailto:jw@inovem.com]
> > Sent: 08 September 2003 09:32
> > To: 'James Developers List'
> > Subject: RE: IMAP Development Pointers
> >
> >
> > I'm slighty confused here.
> > Which is the correct IMAP proposal to use?
> > The IMAP one or IMAP2?
> > Both appear to be IMAP4v1 capable servers, but IMAP2 seems to
> > be more complete
> >
> > Any ideas?
> >
>
>
>
> ---------------------------------------------------------------------
> 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
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
I hate to use discussion forum techniques on a mail list...
*bump* :)
I'm still not sure which IMAP implementation to use
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 08 September 2003 09:32
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> I'm slighty confused here.
> Which is the correct IMAP proposal to use?
> The IMAP one or IMAP2?
> Both appear to be IMAP4v1 capable servers, but IMAP2 seems to
> be more complete
>
> Any ideas?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
I'm slighty confused here.
Which is the correct IMAP proposal to use?
The IMAP one or IMAP2?
Both appear to be IMAP4v1 capable servers, but IMAP2 seems to be more
complete
Any ideas?
-- Jason
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 06 September 2003 21:18
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> I've now had a look and the IMAP code written by Darrell
> (IMAP2 proposal) and I think I can write a bridging class
> between ImapMailBox , ImapStore and the current db: and file:
> repositories. It'll be fun (cough) but it should allow the
> IMAP team to get started.
>
> -- Jason
>
>
>
> ---------------------------------------------------------------------
> 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
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
I've now had a look and the IMAP code written by Darrell (IMAP2 proposal)
and I think I can write a bridging class between ImapMailBox , ImapStore and
the current db: and file: repositories. It'll be fun (cough) but it should
allow the IMAP team to get started.
-- Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 05 September 2003 19:34
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> > In fact I was under the impression that INBOX is a reserved folder
> > name, that it should always be there, and you are not allowed to
> > create subfolders of it. I don't think many enforce the
> no-subfolder
> > of INBOX rule, and I may just be remembering wrong.
>
> I haven't read the IMAP RFCs. I do know that Outlook permits
> you to create sub-folders of INBOX.
>
> > As these IMAP stores are developers and we look to share
> POP3 and IMAP
> > stores, the POP3 handler will just know to always user user.INBOX.
>
> This would make sense for when we re-do the repositories, or
> even if we were to rewrite parts of Cornerstone. But the
> current discussion has been to simply to keys, not
> hierarchies as an intermediate solution allowing immediate
> work on IMAP.
>
> Yes, it is trivial to change the James code to use
> user.INBOX. But then admins would have to rename all of
> their existing file system and JDBC repositories to use it.
> THAT is what I am suggesting we avoid by the simple expedient
> of declaring that user.INBOX === user as a unique (special
> case) mapping. If you have an alternative, that's fine, too.
user.INBOX === user is my prefered option as well.
A user should be allowed to go from PO3 to IMAP and back again
and having user.INBOX === user is a lot easier.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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
RE: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
> In fact I was under the impression that INBOX is a reserved folder name,
> that it should always be there, and you are not allowed to create
> subfolders of it. I don't think many enforce the no-subfolder of INBOX
> rule, and I may just be remembering wrong.
I haven't read the IMAP RFCs. I do know that Outlook permits you to create
sub-folders of INBOX.
> As these IMAP stores are developers and we look to share POP3 and
> IMAP stores, the POP3 handler will just know to always user user.INBOX.
This would make sense for when we re-do the repositories, or even if we were
to rewrite parts of Cornerstone. But the current discussion has been to
simply to keys, not hierarchies as an intermediate solution allowing
immediate work on IMAP.
Yes, it is trivial to change the James code to use user.INBOX. But then
admins would have to rename all of their existing file system and JDBC
repositories to use it. THAT is what I am suggesting we avoid by the simple
expedient of declaring that user.INBOX === user as a unique (special case)
mapping. If you have an alternative, that's fine, too.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP Development Pointers
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> There is no hierarchy. They are just names. The hierarchy is a fiction.
> Just adopt a convention for how IMAP wants to map the names into a
> hierarchy.
>
> No one said that user.folder should be interpreted as a child of the inbox.
> It could be a peer. In terms of the actual storage mapping, they ARE peers;
> there is no hierachy. You might decide to map inbox children (internally)
> as user.INBOX.folder. But I do not want to change the basic inbox name from
> user to user.INBOX because of existing repositories.
In fact I was under the impression that INBOX is a reserved folder name,
that it should always be there, and you are not allowed to create
subfolders of it. I don't think many enforce the no-subfolder of INBOX
rule, and I may just be remembering wrong.
Anyway, the mail servers I am familiar with do place INBOX at the same
left as Sent, Draft, and whatever other top level folders you might have
rather than nesting everything under INBOX. As these IMAP stores are
developers and we look to share POP3 and IMAP stores, the POP3 handler
will just know to always user user.INBOX.
--
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: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I just thought about this under the format where you say
> .select("user.folder") does that automatically assume a
> folder under the INBOX? If so how do you select a folder
> that isn't under the inbox?
There is no hierarchy. They are just names. The hierarchy is a fiction.
Just adopt a convention for how IMAP wants to map the names into a
hierarchy.
No one said that user.folder should be interpreted as a child of the inbox.
It could be a peer. In terms of the actual storage mapping, they ARE peers;
there is no hierachy. You might decide to map inbox children (internally)
as user.INBOX.folder. But I do not want to change the basic inbox name from
user to user.INBOX because of existing repositories.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Hey, sorry I just thought about this under the format where you say
.select("user.folder") does that automatically assume a folder under the
INBOX? If so how do you select a folder that isn't under the inbox?
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Friday, September 05, 2003 9:02 AM
To: 'James Developers List'
Subject: RE: IMAP Development Pointers
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 05 September 2003 15:02
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> That sounds fine to me. I mainly just want something
> working. What locking mechanism are you using with the mbox
> store, though? And how does it recover from power loss
> mid-spool? Just wondering.
The mbox spool uses dot-locking using files (not symlinks) to deal with
other processes accessing the mbox
Because of the way the James POP server works the worst that's likely to
happen is you get some (or all) of the messages twice. This is because
the POP handler deletes all the messages in a store in one go, rather
than a message at a time
>
> Ed
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Friday, September 05, 2003 3:23 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
>
>
<snip'd>
---------------------------------------------------------------------
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
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 05 September 2003 15:02
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> That sounds fine to me. I mainly just want something
> working. What locking mechanism are you using with the mbox
> store, though? And how does it recover from power loss
> mid-spool? Just wondering.
The mbox spool uses dot-locking using files (not symlinks) to deal with
other processes accessing the mbox
Because of the way the James POP server works the worst that's likely to
happen is you get some (or all) of the messages twice. This is because
the POP handler deletes all the messages in a store in one go, rather
than a message at a time
>
> Ed
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Friday, September 05, 2003 3:23 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
>
>
<snip'd>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
That sounds fine to me. I mainly just want something working. What locking
mechanism are you using with the mbox store, though? And how does it
recover from power loss mid-spool? Just wondering.
Ed
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Friday, September 05, 2003 3:23 AM
To: 'James Developers List'
Subject: RE: IMAP Development Pointers
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 04 September 2003 23:54
> To: James Developers List
> Cc: Darrell DeBoer; Kris Bravo; Joe Cheng; Maxwell
> Grender-Jones; Nawwar Kasrawi; Christian Myrvold; Kenny
> Smith; Peter Svensson; Sascha Kulawik
> Subject: RE: IMAP Development Pointers
>
>
> Ed,
>
> Other people who have expressed interest in contributing to IMAP are
> (alphabetically):
>
> Kris Bravo <kr...@corridor-software.us>
> Joe Cheng <co...@joecheng.com>
> Maxwell Grender-Jones <MG...@email.com>
> Nawwar Kasrawi <na...@kasrawi.com>
> Christian Myrvold <ch...@myrvold.info>
> Sascha Kulawik <SK...@kkfnet.de>
> Kenny Smith <ke...@journalscape.com>
> Peter Svensson <pe...@sunfire.nu>
>
> And that is just this year. All it takes to do it is to do
> it. With Jason contributing help on the store changes, if
> just a few people would take the reins on IMAP, it could
> really pick up. Hopefully Darrell could spare some time to
> bring people up to speed.
>
> Jason, if the change to "user.folder" is made, then we can
> use, but don't even need maildir, since the string is just a
> simple key. The hierarchy is a bit of fiction at the moment.
> I mention this because IMAP may benefit from having mail
> attributes, which are supported by the existing JDBC and
> file-system repository formats, but not by the new mbox and
> planned maildir repositories.
>
> So I believe that:
>
> file://var/mail/inboxes/ --> file://var/mail/inboxes/noel (inbox)
> file://var/mail/inboxes/ --> file://var/mail/inboxes/noel.aFolder
> db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel (inbox)
> db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel.aFolder
> mbox:///var/mail/ --> mbox:///var/mail/noel (inbox)
> mbox:///var/mail/ --> mbox:///var/mail/noel.aFolder
>
>Is that what you had in mind? I am not showing a change. I am showing
how the >current code would map the repository name, which is the
portion appended on the >right-hand side.
Spot on Noel! I will test how this works in practise, but I think there
are only minimal code changes (if any) required to get folders working
in db[file]: and file:
I may support attributes in mbox by writing them into the headers of
each message. Other implementations do this, but it's highly inefficent
in terms of I/O. I think maildir can go for the moment as most people
use file: or db[file]: stores.
--- Noel
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 04 September 2003 23:54
> To: James Developers List
> Cc: Darrell DeBoer; Kris Bravo; Joe Cheng; Maxwell
> Grender-Jones; Nawwar Kasrawi; Christian Myrvold; Kenny
> Smith; Peter Svensson; Sascha Kulawik
> Subject: RE: IMAP Development Pointers
>
>
> Ed,
>
> Other people who have expressed interest in contributing to IMAP are
> (alphabetically):
>
> Kris Bravo <kr...@corridor-software.us>
> Joe Cheng <co...@joecheng.com>
> Maxwell Grender-Jones <MG...@email.com>
> Nawwar Kasrawi <na...@kasrawi.com>
> Christian Myrvold <ch...@myrvold.info>
> Sascha Kulawik <SK...@kkfnet.de>
> Kenny Smith <ke...@journalscape.com>
> Peter Svensson <pe...@sunfire.nu>
>
> And that is just this year. All it takes to do it is to do
> it. With Jason contributing help on the store changes, if
> just a few people would take the reins on IMAP, it could
> really pick up. Hopefully Darrell could spare some time to
> bring people up to speed.
>
> Jason, if the change to "user.folder" is made, then we can
> use, but don't even need maildir, since the string is just a
> simple key. The hierarchy is a bit of fiction at the moment.
> I mention this because IMAP may benefit from having mail
> attributes, which are supported by the existing JDBC and
> file-system repository formats, but not by the new mbox and
> planned maildir repositories.
>
> So I believe that:
>
> file://var/mail/inboxes/ --> file://var/mail/inboxes/noel (inbox)
> file://var/mail/inboxes/ --> file://var/mail/inboxes/noel.aFolder
> db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel (inbox)
> db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel.aFolder
> mbox:///var/mail/ --> mbox:///var/mail/noel (inbox)
> mbox:///var/mail/ --> mbox:///var/mail/noel.aFolder
>
>Is that what you had in mind? I am not showing a change. I am showing
how the >current code would map the repository name, which is the
portion appended on the >right-hand side.
Spot on Noel! I will test how this works in practise, but I think there
are only minimal code changes (if any) required to get folders working
in db[file]: and file:
I may support attributes in mbox by writing them into the headers of
each message. Other implementations do this, but it's highly inefficent
in terms of I/O. I think maildir can go for the moment as most people
use file: or db[file]: stores.
--- Noel
---------------------------------------------------------------------
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
Re: IMAP Development Pointers
Posted by Serge Knystautas <se...@lokitech.com>.
Joe Cheng wrote:
> ...I
> was surprised to discover that none of the "mainstream" Windows e-mail
> clients out there even use server-side searching (I believe I tested
> Outlook Express, Outlook, Mozilla... it was a while ago though). I
> think the most common client that does is Mutt (or Pine? I forget).
What are you talking about? I can personally vouch that for 6 years
I've been using IMAP with a Windows client that Outlook Express,
Netscape Mail, Mozilla, and Thunderbird have supported server-side
searching.
--
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: IMAP Development Pointers
Posted by Joe Cheng <jm...@alum.mit.edu>.
For what it's worth, I had more or less completed a mailstore for my own
IMAP server after I decided not to work directly on James.
Here are some performance stats:
http://www.joecheng.com/blog/entries/Mailstoreperformancetests.html
In my mailstore implementation, each folder is a directory and the raw
RFC822 of each message is stored as its own file. There is also a
metadata repository per folder; this is managed using Prevayler. My
rationale here was that most operations that involve many messages only
involve the metadata, so by keeping that stuff small and together you
can avoid thrashing when, for example, you want to get all the unread
UIDs in a folder with 100,000 e-mails (takes 40ms with my
implementation, on my laptop, with 1 concurrent user).
The metadata doesn't help when doing the only other operation that
potentially goes across all files: doing a search. But if you're using
Lucene or something similar, then it basically doesn't matter. Also, I
was surprised to discover that none of the "mainstream" Windows e-mail
clients out there even use server-side searching (I believe I tested
Outlook Express, Outlook, Mozilla... it was a while ago though). I
think the most common client that does is Mutt (or Pine? I forget).
E-mail me if you want my source, or if I can otherwise be of assistance.
-jmc
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
Ed,
Other people who have expressed interest in contributing to IMAP are
(alphabetically):
Kris Bravo <kr...@corridor-software.us>
Joe Cheng <co...@joecheng.com>
Maxwell Grender-Jones <MG...@email.com>
Nawwar Kasrawi <na...@kasrawi.com>
Christian Myrvold <ch...@myrvold.info>
Sascha Kulawik <SK...@kkfnet.de>
Kenny Smith <ke...@journalscape.com>
Peter Svensson <pe...@sunfire.nu>
And that is just this year. All it takes to do it is to do it. With Jason
contributing help on the store changes, if just a few people would take the
reins on IMAP, it could really pick up. Hopefully Darrell could spare some
time to bring people up to speed.
Jason, if the change to "user.folder" is made, then we can use, but don't
even need maildir, since the string is just a simple key. The hierarchy is
a bit of fiction at the moment. I mention this because IMAP may benefit
from having mail attributes, which are supported by the existing JDBC and
file-system repository formats, but not by the new mbox and planned maildir
repositories.
So I believe that:
file://var/mail/inboxes/ --> file://var/mail/inboxes/noel (inbox)
file://var/mail/inboxes/ --> file://var/mail/inboxes/noel.aFolder
db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel (inbox)
db[file]://maildb/inbox/ --> db[file]://maildb/inbox/noel.aFolder
mbox:///var/mail/ --> mbox:///var/mail/noel (inbox)
mbox:///var/mail/ --> mbox:///var/mail/noel.aFolder
Is that what you had in mind? I am not showing a change. I am showing how
the current code would map the repository name, which is the portion
appended on the right-hand side.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: IMAP Development Pointers
Posted by Serge Knystautas <se...@lokitech.com>.
Edward Flick wrote:
> Just out of curiosity, is there anything wrong with just using the
> filesystem? Folders work wonders :-P. And sets of enumerated files for
> messages would be nice, easy, and quick to implement, and I guess some quick
> and easy link file for common boxes between accounts. What do you think?
> Of course this is before really looking through much code. But I like to
> get started on the right foot.
>
> Also, shouldn't the POP3 store be the same as the IMAP store (with pop3
> obviously only having the top of the tree as the mailbox)?
Hi, Pandora.
Generally yes, but you need to look through some of the code to see what
you're unleashing.
--
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: IMAP Development Pointers
Posted by Serge Knystautas <se...@lokitech.com>.
Edward Flick wrote:
> Yeah, maildirs seem pretty effective as a store. Thats actually what I was
> hinting at (with a link file instead of real links as this is a java program
> and will be running on platforms which don't support real links). I don't
> buy into the idea that creating multiple files will cause much more disk
> thrashing, as a spool file can be scattered all of over the drive too.
Agreed. Individual files per messages is much better than single files
per folder (I would think).
> Although, the open/close efficiency issue is real, BUT I think this can be
> counteracted with a good full-text index file. Also, thanks to the newer
> journaling file systems, it would be a lot easier to guarantee that a
> message is uncorrupted. Although, I definetely think the indexing system
> should
> be implemented after a simple maildir implementation is put into place.
I would recommend Lucene for the indexing. API is a bit goofy, but it's
very fast, a Jakarta project, and I'm familiar with it if you have
questions.
> Anyways, this would just be a step to at least get this into something close
> to a beta phase. What do you guys think?
Sounds great to me. I believe the biggest hurdle was just the stores,
and then we could at least start testing more widely.
--
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: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
I see nothing wrong with .select("username.foldername"). The only other way
I would think of would be a .select("username").select("folder1.folder2"),
this way you could store the user repository in a var and would save from
having to do a string concat every call, when mapping from the IMAP SELECT
command. Although, I haven't looked through the james source much, what do
you think?
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Thursday, September 04, 2003 11:39 AM
To: 'James Developers List'
Subject: RE: IMAP Development Pointers
No worries Ed. I've just written the mbox repository so I've a good idea
what works etc. in James
My only comment is the use of the .select() method. When a user's
repository is opened the method call is .select("username")
To access folders I'd propose the use of .select("username.foldername")
when the server want a folders contents.
Folder links are interesting ;) I'll have a think about those too.
Shared folders are a LOT of pain due to the fact that you'd have a store
the read state for lots of people at the same time. Not nice.
Any comments on this?
-- Jason
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 04 September 2003 17:43
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Hi Jason,
> Boy and I was thinking about doing it myself, but if you want
> to I am not going to stop you, hehe :-P. Just a note, there
> should probably be folder link files too, right?, if you want
> to be able to have shared message spaces. Do you think this
> is the way to go, also? I'm just tossing out ideas, and am
> open to others.
>
> Ed
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Thursday, September 04, 2003 11:07 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> I shall have a think then (and set about doing it)
> DJB's site has a good explanation on how maildir works
> http://qmail.plig.org/man/man5/maildir.html
>
> -- Jason
>
>
> > -----Original Message-----
> > From: Edward Flick [mailto:eddy@cdf-imaging.com]
> > Sent: 04 September 2003 15:24
> > To: James Developers List
> > Subject: RE: IMAP Development Pointers
> >
> >
> > Yeah, maildirs seem pretty effective as a store. Thats
> actually what
> > I was hinting at (with a link file instead of real links as
> this is a
> > java program and will be running on platforms which don't
> support real
> > links). I don't buy into the idea that creating multiple
> files will
> > cause much more disk thrashing, as a spool file can be
> scattered all
> > of over the drive too. Although, the open/close efficiency issue is
> > real, BUT I think this can be counteracted with a good
> > full-text index file. Also, thanks to the newer journaling
> > file systems, it would be a lot easier to guarantee that a
> > message is uncorrupted. Although, I definetely think the
> > indexing system should be implemented after a simple maildir
> > implementation is put into place. Anyways, this would just be
> > a step to at least get this into something close to a beta
> > phase. What do you guys think?
> >
> > -----Original Message-----
> > From: Jason Webb [mailto:jw@inovem.com]
> > Sent: Thursday, September 04, 2003 3:02 AM
> > To: 'James Developers List'
> > Subject: RE: IMAP Development Pointers
> >
> >
> > If there is enough interest or need I will write a maildir-style
> > repository. This is used by qmail and Courier-IMAP to great effect
> > and provides folders etc., and it's safe(ish) over networked file
> > systems. The current repositories are less than ideal other
> than for
> > folder based storage ,particularly the mbox one ;)
> >
> > -----Original Message-----
> > From: Jim Wright [mailto:jimw@paneris.org]
> > Sent: Wednesday, September 03, 2003 5:40 PM
> > To: James Developers List
> > Subject: Re: IMAP Development Pointers
> >
> >
> > Hi Edward,
> >
> > I have University of Washington IMAP on my Linux machine
> > and use an experimental format mx which is as you describe.
> To quote
> > the docs:
> >
> > . mx This is an experimental format, and may be removed
> in a future
> > release. ...
> >
> > [snip]
> >
> > mx is somewhat inefficient; the entire directory must be read
> > and each file stat()'d. We found it intolerable for a
> > moderate sized mailbox (2000 messages) and have more or less
> > abandoned it.
> >
> > [snip]
> >
> >
> > There's a general reason why file/message formats are a
> bad idea.
> > Just about every filesystem in existance serializes
> file creation
> > and
> > deletions because these manipulate the free space map.
> This turns
> > out
> > to be an enormous problem when you start creating/deleting more
> > than a
> > few messages per second; you spend all your time
> thrashing in the
> > filesystem.
> >
> > It is also extremely slow to do a text search through a
> > file/message format mailbox. All of those open()s and close()s
> > really
> > add up to major filesystem thrashing.
> >
> > I was not completely convinced by this. File system devices are
> > getting faster for a start.
> >
> >
> >
> ---------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
No worries Ed. I've just written the mbox repository so I've a good idea
what works etc. in James
My only comment is the use of the .select() method. When a user's
repository is opened the method call is .select("username")
To access folders I'd propose the use of .select("username.foldername")
when the server want a folders contents.
Folder links are interesting ;) I'll have a think about those too.
Shared folders are a LOT of pain due to the fact that you'd have a store
the read state for lots of people at the same time. Not nice.
Any comments on this?
-- Jason
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 04 September 2003 17:43
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Hi Jason,
> Boy and I was thinking about doing it myself, but if you want
> to I am not going to stop you, hehe :-P. Just a note, there
> should probably be folder link files too, right?, if you want
> to be able to have shared message spaces. Do you think this
> is the way to go, also? I'm just tossing out ideas, and am
> open to others.
>
> Ed
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Thursday, September 04, 2003 11:07 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> I shall have a think then (and set about doing it)
> DJB's site has a good explanation on how maildir works
> http://qmail.plig.org/man/man5/maildir.html
>
> -- Jason
>
>
> > -----Original Message-----
> > From: Edward Flick [mailto:eddy@cdf-imaging.com]
> > Sent: 04 September 2003 15:24
> > To: James Developers List
> > Subject: RE: IMAP Development Pointers
> >
> >
> > Yeah, maildirs seem pretty effective as a store. Thats
> actually what
> > I was hinting at (with a link file instead of real links as
> this is a
> > java program and will be running on platforms which don't
> support real
> > links). I don't buy into the idea that creating multiple
> files will
> > cause much more disk thrashing, as a spool file can be
> scattered all
> > of over the drive too. Although, the open/close efficiency issue is
> > real, BUT I think this can be counteracted with a good
> > full-text index file. Also, thanks to the newer journaling
> > file systems, it would be a lot easier to guarantee that a
> > message is uncorrupted. Although, I definetely think the
> > indexing system should be implemented after a simple maildir
> > implementation is put into place. Anyways, this would just be
> > a step to at least get this into something close to a beta
> > phase. What do you guys think?
> >
> > -----Original Message-----
> > From: Jason Webb [mailto:jw@inovem.com]
> > Sent: Thursday, September 04, 2003 3:02 AM
> > To: 'James Developers List'
> > Subject: RE: IMAP Development Pointers
> >
> >
> > If there is enough interest or need I will write a maildir-style
> > repository. This is used by qmail and Courier-IMAP to great effect
> > and provides folders etc., and it's safe(ish) over networked file
> > systems. The current repositories are less than ideal other
> than for
> > folder based storage ,particularly the mbox one ;)
> >
> > -----Original Message-----
> > From: Jim Wright [mailto:jimw@paneris.org]
> > Sent: Wednesday, September 03, 2003 5:40 PM
> > To: James Developers List
> > Subject: Re: IMAP Development Pointers
> >
> >
> > Hi Edward,
> >
> > I have University of Washington IMAP on my Linux machine
> > and use an experimental format mx which is as you describe.
> To quote
> > the docs:
> >
> > . mx This is an experimental format, and may be removed
> in a future
> > release. ...
> >
> > [snip]
> >
> > mx is somewhat inefficient; the entire directory must be read
> > and each file stat()'d. We found it intolerable for a
> > moderate sized mailbox (2000 messages) and have more or less
> > abandoned it.
> >
> > [snip]
> >
> >
> > There's a general reason why file/message formats are a
> bad idea.
> > Just about every filesystem in existance serializes
> file creation
> > and
> > deletions because these manipulate the free space map.
> This turns
> > out
> > to be an enormous problem when you start creating/deleting more
> > than a
> > few messages per second; you spend all your time
> thrashing in the
> > filesystem.
> >
> > It is also extremely slow to do a text search through a
> > file/message format mailbox. All of those open()s and close()s
> > really
> > add up to major filesystem thrashing.
> >
> > I was not completely convinced by this. File system devices are
> > getting faster for a start.
> >
> >
> >
> ---------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> 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
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Hi Jason,
Boy and I was thinking about doing it myself, but if you want to I am not
going to stop you, hehe :-P. Just a note, there should probably be folder
link files too, right?, if you want to be able to have shared message
spaces. Do you think this is the way to go, also? I'm just tossing out
ideas, and am open to others.
Ed
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Thursday, September 04, 2003 11:07 AM
To: 'James Developers List'
Subject: RE: IMAP Development Pointers
I shall have a think then (and set about doing it)
DJB's site has a good explanation on how maildir works
http://qmail.plig.org/man/man5/maildir.html
-- Jason
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 04 September 2003 15:24
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Yeah, maildirs seem pretty effective as a store. Thats
> actually what I was hinting at (with a link file instead of
> real links as this is a java program and will be running on
> platforms which don't support real links). I don't buy into
> the idea that creating multiple files will cause much more
> disk thrashing, as a spool file can be scattered all of over
> the drive too. Although, the open/close efficiency issue is
> real, BUT I think this can be counteracted with a good
> full-text index file. Also, thanks to the newer journaling
> file systems, it would be a lot easier to guarantee that a
> message is uncorrupted. Although, I definetely think the
> indexing system should be implemented after a simple maildir
> implementation is put into place. Anyways, this would just be
> a step to at least get this into something close to a beta
> phase. What do you guys think?
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Thursday, September 04, 2003 3:02 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> If there is enough interest or need I will write a
> maildir-style repository. This is used by qmail and
> Courier-IMAP to great effect and provides folders etc., and
> it's safe(ish) over networked file systems. The current
> repositories are less than ideal other than for folder based
> storage ,particularly the mbox one ;)
>
> -----Original Message-----
> From: Jim Wright [mailto:jimw@paneris.org]
> Sent: Wednesday, September 03, 2003 5:40 PM
> To: James Developers List
> Subject: Re: IMAP Development Pointers
>
>
> Hi Edward,
>
> I have University of Washington IMAP on my Linux machine
> and use an experimental format mx which is as you describe.
> To quote the docs:
>
> . mx This is an experimental format, and may be removed in a future
> release. ...
>
> [snip]
>
> mx is somewhat inefficient; the entire directory must be read
> and each file stat()'d. We found it intolerable for a
> moderate sized mailbox (2000 messages) and have more or less
> abandoned it.
>
> [snip]
>
>
> There's a general reason why file/message formats are a bad idea.
> Just about every filesystem in existance serializes file
> creation and
> deletions because these manipulate the free space map.
> This turns out
> to be an enormous problem when you start
> creating/deleting more than a
> few messages per second; you spend all your time thrashing in the
> filesystem.
>
> It is also extremely slow to do a text search through a
> file/message format mailbox. All of those open()s and
> close()s really
> add up to major filesystem thrashing.
>
> I was not completely convinced by this. File system devices
> are getting faster for a start.
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
I shall have a think then (and set about doing it)
DJB's site has a good explanation on how maildir works
http://qmail.plig.org/man/man5/maildir.html
-- Jason
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 04 September 2003 15:24
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Yeah, maildirs seem pretty effective as a store. Thats
> actually what I was hinting at (with a link file instead of
> real links as this is a java program and will be running on
> platforms which don't support real links). I don't buy into
> the idea that creating multiple files will cause much more
> disk thrashing, as a spool file can be scattered all of over
> the drive too. Although, the open/close efficiency issue is
> real, BUT I think this can be counteracted with a good
> full-text index file. Also, thanks to the newer journaling
> file systems, it would be a lot easier to guarantee that a
> message is uncorrupted. Although, I definetely think the
> indexing system should be implemented after a simple maildir
> implementation is put into place. Anyways, this would just be
> a step to at least get this into something close to a beta
> phase. What do you guys think?
>
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: Thursday, September 04, 2003 3:02 AM
> To: 'James Developers List'
> Subject: RE: IMAP Development Pointers
>
>
> If there is enough interest or need I will write a
> maildir-style repository. This is used by qmail and
> Courier-IMAP to great effect and provides folders etc., and
> it's safe(ish) over networked file systems. The current
> repositories are less than ideal other than for folder based
> storage ,particularly the mbox one ;)
>
> -----Original Message-----
> From: Jim Wright [mailto:jimw@paneris.org]
> Sent: Wednesday, September 03, 2003 5:40 PM
> To: James Developers List
> Subject: Re: IMAP Development Pointers
>
>
> Hi Edward,
>
> I have University of Washington IMAP on my Linux machine
> and use an experimental format mx which is as you describe.
> To quote the docs:
>
> . mx This is an experimental format, and may be removed in a future
> release. ...
>
> [snip]
>
> mx is somewhat inefficient; the entire directory must be read
> and each file stat()'d. We found it intolerable for a
> moderate sized mailbox (2000 messages) and have more or less
> abandoned it.
>
> [snip]
>
>
> There's a general reason why file/message formats are a bad idea.
> Just about every filesystem in existance serializes file
> creation and
> deletions because these manipulate the free space map.
> This turns out
> to be an enormous problem when you start
> creating/deleting more than a
> few messages per second; you spend all your time thrashing in the
> filesystem.
>
> It is also extremely slow to do a text search through a
> file/message format mailbox. All of those open()s and
> close()s really
> add up to major filesystem thrashing.
>
> I was not completely convinced by this. File system devices
> are getting faster for a start.
>
>
> ---------------------------------------------------------------------
> 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
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Yeah, maildirs seem pretty effective as a store. Thats actually what I was
hinting at (with a link file instead of real links as this is a java program
and will be running on platforms which don't support real links). I don't
buy into the idea that creating multiple files will cause much more disk
thrashing, as a spool file can be scattered all of over the drive too.
Although, the open/close efficiency issue is real, BUT I think this can be
counteracted with a good full-text index file. Also, thanks to the newer
journaling file systems, it would be a lot easier to guarantee that a
message is uncorrupted. Although, I definetely think the indexing system
should
be implemented after a simple maildir implementation is put into place.
Anyways, this would just be a step to at least get this into something close
to a beta phase. What do you guys think?
-----Original Message-----
From: Jason Webb [mailto:jw@inovem.com]
Sent: Thursday, September 04, 2003 3:02 AM
To: 'James Developers List'
Subject: RE: IMAP Development Pointers
If there is enough interest or need I will write a maildir-style
repository. This is used by qmail and Courier-IMAP to great effect and
provides folders etc., and it's safe(ish) over networked file systems.
The current repositories are less than ideal other than for folder based
storage ,particularly the mbox one ;)
-----Original Message-----
From: Jim Wright [mailto:jimw@paneris.org]
Sent: Wednesday, September 03, 2003 5:40 PM
To: James Developers List
Subject: Re: IMAP Development Pointers
Hi Edward,
I have University of Washington IMAP on my Linux machine
and use an experimental format mx which is as you describe.
To quote the docs:
. mx This is an experimental format, and may be removed in a future
release. ...
[snip]
mx is somewhat inefficient; the entire directory must be read
and each file stat()'d. We found it intolerable for a
moderate sized mailbox (2000 messages) and have more or less
abandoned it.
[snip]
There's a general reason why file/message formats are a bad idea.
Just about every filesystem in existance serializes file creation and
deletions because these manipulate the free space map. This turns out
to be an enormous problem when you start creating/deleting more than a
few messages per second; you spend all your time thrashing in the
filesystem.
It is also extremely slow to do a text search through a
file/message format mailbox. All of those open()s and close()s really
add up to major filesystem thrashing.
I was not completely convinced by this. File system devices are getting
faster for a start.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
Support for maildir would be helpful, but one issue is how to express the
hierarchy. I think that is really a key issue. For example, is there one
repository, or does each folder look like a repository? This is really an
important consideration, both in terms of abstraction and implementation.
Repositories today gloss over the distinction of store and folder because
there is only one folder, really each repository is a separate folder.
JavaMail has folders within a store. Serge and I have both proposed name
space federation that allow folders to be within a store, but do not require
it. Within JavaMail that would have to be some sort of federating provider.
With JNDI it is more transparent.
This distinction also provides us a path now to add Folders, since it is
just playing with the namespace, and can be compatible (even if not ideal)
with the current Cornerstone Store package. As you noted elsewhere:
> My only comment is the use of the .select() method. When a user's
> repository is opened the method call is .select("username")
> To access folders I'd propose the use of .select("username.foldername")
> when the server want a folders contents.
which fits with what I said, too. The string "username.foldername" is just
a name (key), so we can use it with the current infrastructure.
Don't worry too much about links. When we get JNDI into the mix, it can
handle all of that, and we may just need the single level implementation
(although it would be nice to optimize moving and sharing messages under the
covers).
I agree with Serge about using Lucene to provide indexing for IMAP. But
before we do that, here is a serious question. Does anyone want to help
with Eyebrowse development, either in eyebrowse.tigris.org or here?
Eyebrowse needs work, but core portions of it build indices using Lucene for
full-text, and also build message, author, thread, etc., indices in a
relational database. You can see it working at
http://nagoya.apache.org/eyebrowse/. The current version of eyebrowse
requires too much manual and scripted administration, but it occurs to me
that if it were integrated with the IMAP service, it could be a lot more
automatic. Either way, we might want to look at the code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: how to share between incoming msgs and outgoing msgs
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Looking at the RecipientIsLocal matcher, a test to see if the message is incoming (going to a local user) is the following:
if (mailetContext.isLocalServer(recipient.getHost()) && mailetContext.isLocalUser(recipient.getUser())) {
// is local
}
But I think, reading your clarification, that there is a misunderstanding: if the message comes from a local user, and goes to a (possibly different) local user, it will be processed *only once*:
client -> james spool -> begin mailet processing -> local delivery (inboxes) -> client
Only if the message is *forwarded/resent etc.* it would be processed twice (split):
client -> james spool -> begin mailet processing ... forward! ... more mailet processing -> to ghost or local delivery (inboxes) -> client
|
+-> james spool => begin mailet processing => local delivery (inboxes) => client
Vincenzo
> -----Original Message-----
> From: Marcello Marangio [mailto:m.marangio@tno.it]
> Sent: giovedi 4 settembre 2003 12.24
> To: James Developers List
> Subject: R: how to share between incoming msgs and outgoing msgs
>
>
> Vincenzo,
> thanks for the answer.
> My scenario is slightly different.
> I can have e-mails msgs sent between two users belonging to the
> same domain,
> and I would like to make my mailet (triggered with the matcher "All", for
> example) process the message twice: the first time when the mailet catches
> the outgoing mail and the second time when the recepients
> actually receives
> it, i.e. just before the mail is forwarded to the recipient. Note: in both
> cases the mailet is the same!
> Is there a standard method to do this?
>
> Grazie
> Marcello
>
>
>
> > -----Messaggio originale-----
> > Da: Vincenzo Gianferrari Pini
> > [mailto:vincenzo.gianferraripini@praxis.it]
> > Inviato: giovedi 4 settembre 2003 11.12
> > A: James Developers List
> > Oggetto: RE: how to share between incoming msgs and outgoing msgs
> >
> >
> > Marcello,
> >
> > Look at the "standard" config.xml logic:
> >
> > ...
> > <!-- If the recipient is for a local account, deliver it
> > locally -->
> > <mailet match="RecipientIsLocal" class="LocalDelivery"/>
> >
> > <!-- If the host is handled by this server and it did
> not get -->
> > <!-- locally delivered, this is an invalid recipient -->
> > <mailet match="HostIsLocal" class="ToProcessor">
> > <processor>local-address-error</processor>
> > <notice>Unknown recipient</notice>
> > </mailet>
> > ...
> >
> > if we are here it is an outgoing message
> >
> > Look at the RecipientIsLocal and HostIsLocal matchers.
> >
> > Ciao,
> > Vincenzo
> >
> > > -----Original Message-----
> > > From: Marcello Marangio [mailto:m.marangio@tno.it]
> > > Sent: giovedi 4 settembre 2003 10.42
> > > To: James Developers List
> > > Subject: how to share between incoming msgs and outgoing msgs
> > >
> > >
> > > Hi all
> > > I have a newbie problem: how can I make a mailet (or a matcher)
> > understand
> > > that a message is an outgoing rather than an incoming message?
> > > I couldn't find anything in the SMTP standard, nor in james docs.
> > > Can anybody please help me?
> > >
> > > Thanks
> > > Marcello
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
R: how to share between incoming msgs and outgoing msgs
Posted by Marcello Marangio <m....@tno.it>.
Vincenzo,
thanks for the answer.
My scenario is slightly different.
I can have e-mails msgs sent between two users belonging to the same domain,
and I would like to make my mailet (triggered with the matcher "All", for
example) process the message twice: the first time when the mailet catches
the outgoing mail and the second time when the recepients actually receives
it, i.e. just before the mail is forwarded to the recipient. Note: in both
cases the mailet is the same!
Is there a standard method to do this?
Grazie
Marcello
> -----Messaggio originale-----
> Da: Vincenzo Gianferrari Pini
> [mailto:vincenzo.gianferraripini@praxis.it]
> Inviato: giovedi 4 settembre 2003 11.12
> A: James Developers List
> Oggetto: RE: how to share between incoming msgs and outgoing msgs
>
>
> Marcello,
>
> Look at the "standard" config.xml logic:
>
> ...
> <!-- If the recipient is for a local account, deliver it
> locally -->
> <mailet match="RecipientIsLocal" class="LocalDelivery"/>
>
> <!-- If the host is handled by this server and it did not get -->
> <!-- locally delivered, this is an invalid recipient -->
> <mailet match="HostIsLocal" class="ToProcessor">
> <processor>local-address-error</processor>
> <notice>Unknown recipient</notice>
> </mailet>
> ...
>
> if we are here it is an outgoing message
>
> Look at the RecipientIsLocal and HostIsLocal matchers.
>
> Ciao,
> Vincenzo
>
> > -----Original Message-----
> > From: Marcello Marangio [mailto:m.marangio@tno.it]
> > Sent: giovedi 4 settembre 2003 10.42
> > To: James Developers List
> > Subject: how to share between incoming msgs and outgoing msgs
> >
> >
> > Hi all
> > I have a newbie problem: how can I make a mailet (or a matcher)
> understand
> > that a message is an outgoing rather than an incoming message?
> > I couldn't find anything in the SMTP standard, nor in james docs.
> > Can anybody please help me?
> >
> > Thanks
> > Marcello
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: how to share between incoming msgs and outgoing msgs
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Marcello,
Look at the "standard" config.xml logic:
...
<!-- If the recipient is for a local account, deliver it locally -->
<mailet match="RecipientIsLocal" class="LocalDelivery"/>
<!-- If the host is handled by this server and it did not get -->
<!-- locally delivered, this is an invalid recipient -->
<mailet match="HostIsLocal" class="ToProcessor">
<processor>local-address-error</processor>
<notice>Unknown recipient</notice>
</mailet>
...
if we are here it is an outgoing message
Look at the RecipientIsLocal and HostIsLocal matchers.
Ciao,
Vincenzo
> -----Original Message-----
> From: Marcello Marangio [mailto:m.marangio@tno.it]
> Sent: giovedi 4 settembre 2003 10.42
> To: James Developers List
> Subject: how to share between incoming msgs and outgoing msgs
>
>
> Hi all
> I have a newbie problem: how can I make a mailet (or a matcher) understand
> that a message is an outgoing rather than an incoming message?
> I couldn't find anything in the SMTP standard, nor in james docs.
> Can anybody please help me?
>
> Thanks
> Marcello
>
>
> ---------------------------------------------------------------------
> 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
how to share between incoming msgs and outgoing msgs
Posted by Marcello Marangio <m....@tno.it>.
Hi all
I have a newbie problem: how can I make a mailet (or a matcher) understand
that a message is an outgoing rather than an incoming message?
I couldn't find anything in the SMTP standard, nor in james docs.
Can anybody please help me?
Thanks
Marcello
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Jason Webb <jw...@inovem.com>.
If there is enough interest or need I will write a maildir-style
repository. This is used by qmail and Courier-IMAP to great effect and
provides folders etc., and it's safe(ish) over networked file systems.
The current repositories are less than ideal other than for folder based
storage ,particularly the mbox one ;)
-- Jason
> -----Original Message-----
> From: Edward Flick [mailto:eddy@cdf-imaging.com]
> Sent: 03 September 2003 21:56
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Just out of curiosity, is there anything wrong with just
> using the filesystem? Folders work wonders :-P. And sets of
> enumerated files for messages would be nice, easy, and quick
> to implement, and I guess some quick and easy link file for
> common boxes between accounts. What do you think? Of course
> this is before really looking through much code. But I like
> to get started on the right foot.
>
> Also, shouldn't the POP3 store be the same as the IMAP store
> (with pop3 obviously only having the top of the tree as the mailbox)?
>
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Wednesday, September 03, 2003 3:22 PM
> To: James Developers List
> Subject: RE: IMAP Development Pointers
>
>
> Edward,
>
> That would be great. We've had a number of developers
> "threaten" ;-) to work on IMAP, but no one has really stepped
> up to it other than DdB.
>
> AFAIK, the big problem is the lack of an adequate message
> store for the hierarchy. I am starting to work on JNDI/LDAP
> stuff. I will bring it on-line as soon as I have something
> worth showing. Meanwhile, the IMAP2 proposal uses an in-memory store.
>
> Best thing would be to get in touch with Darrel and/or review
> the two code bases.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: IMAP Development Pointers
Posted by Edward Flick <ed...@cdf-imaging.com>.
Just out of curiosity, is there anything wrong with just using the
filesystem? Folders work wonders :-P. And sets of enumerated files for
messages would be nice, easy, and quick to implement, and I guess some quick
and easy link file for common boxes between accounts. What do you think?
Of course this is before really looking through much code. But I like to
get started on the right foot.
Also, shouldn't the POP3 store be the same as the IMAP store (with pop3
obviously only having the top of the tree as the mailbox)?
-----Original Message-----
From: Noel J. Bergman [mailto:noel@devtech.com]
Sent: Wednesday, September 03, 2003 3:22 PM
To: James Developers List
Subject: RE: IMAP Development Pointers
Edward,
That would be great. We've had a number of developers "threaten" ;-) to
work on IMAP, but no one has really stepped up to it other than DdB.
AFAIK, the big problem is the lack of an adequate message store for the
hierarchy. I am starting to work on JNDI/LDAP stuff. I will bring it
on-line as soon as I have something worth showing. Meanwhile, the IMAP2
proposal uses an in-memory store.
Best thing would be to get in touch with Darrel and/or review the two code
bases.
--- Noel
---------------------------------------------------------------------
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
RE: IMAP Development Pointers
Posted by "Noel J. Bergman" <no...@devtech.com>.
Edward,
That would be great. We've had a number of developers "threaten" ;-) to
work on IMAP, but no one has really stepped up to it other than DdB.
AFAIK, the big problem is the lack of an adequate message store for the
hierarchy. I am starting to work on JNDI/LDAP stuff. I will bring it
on-line as soon as I have something worth showing. Meanwhile, the IMAP2
proposal uses an in-memory store.
Best thing would be to get in touch with Darrel and/or review the two code
bases.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org