james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <Danny_An...@slc.co.uk>
Subject RE: Repositories
Date Wed, 22 Dec 2004 14:44:51 GMT
I vote for move them into James proper.

You can submit the change to cornerstone too, but lets not loose sight of
the code.


|         |           "Jason Webb"     |
|         |           <jw@inovem.com>  |
|         |                            |
|         |           22/12/2004 02:22 |
|         |           PM               |
|         |           Please respond to|
|         |           "James Developers|
|         |           List"            |
|         |                            |
  |       To:       "'James Developers List'" <server-dev@james.apache.org>, <soren.hilmer@tietoenator.com>
  |       cc:                                                                            
  |       Subject:  RE: Repositories                                                     

> -----Original Message-----
> From: Soren Hilmer [mailto:soren.hilmer@tietoenator.com]
> Sent: 22 December 2004 14:15
> To: James Developers List
> Subject: Re: Repositories
> On Wednesday 22 December 2004 13:50, Danny Angus wrote:
> >
> > Soren,
> > Derby would be embedded in James, it would not be visible to users at
> all,
> > and require no additional admin or configuration.
> > The messages would not be visible in the filesystem, but that would be
> the
> > only drawback.
> Okay, sounds a little better.
> Still I must say I prefer the file repositories, it is a lot easier to
> support
> a mailserver when you can read the mails currently in process directly
> from
> the filesystem.
> This is AFAIK also the approach serious mailservers like Postfix does
> things.
> If we go for an all DB solution. We need better tools to show the
> repositories
> and messages within them.
> I can see the problems about destroying/renaming repositories, because
> those
> operations are not supported by CornerStone.
> Could it be a compromise that we require DB repositories only when IMAP
> used, and thereby allowing existing setups to continue with file/filedb
> repositories?

One repository to rule them all, one repository to find them. One
to rule them all and in the darkness bind them :) (Apologies to JRR

One of my primary design goals is to make sure the user can access their
email using POP3 or IMAP4 in whatever way they choose. I will implement the
file based repositories to have the required methods for IMAP. This will
involve changes to the cornerstone classes. Is the best thing to do with
these changes to move them into James proper or to attempt to submit
to the Cornerstone project?

> --Søren
> >
> > d.
> >
> >

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

The information in this e-mail is confidential and for use by the addressee(s) only. If you
are not the intended recipient (or responsible for delivery of the message to the intended
recipient) please notify us immediately on 0141 306 2050 and delete the message from your
computer. You may not copy or forward it or use or disclose its contents to any other person.
As Internet communications are capable of data corruption Student Loans Company Limited does
not accept any  responsibility for changes made to this message after it was sent. For this
reason it may be inappropriate to rely on advice or opinions contained in an e-mail without
obtaining written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to scan attachments
(if any). Opinions and views expressed in this e-mail are those of the sender and may not
reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer


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

View raw message