james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent de Lau" <vinc...@delau.nl>
Subject Storage architecture (was: Serializing Users in FilesForwarding mail to NNTP)
Date Sun, 20 Apr 2003 23:42:10 GMT
First of all, let me introduce myself. I'm lurking the list for a few weeks
now, since the James project was mentioned in the OOogw (OpenOffice.org
groupware) project mailinglist. (http://groupware.openoffice.org/) I have
experience with Microsoft Exchange as administrator and posted some thoughts
about a groupware architecture for OOogw.

I wouldn't call myself a Java programmer. I can read complex source and
write a HelloWorld app :)

> The idea was to have something valuable out and move to a more standard
> repository when available and make switch over as clean as possible.
>
> > I have heard rumours of work being done in this area for James 1.3. Is
> > there any documentation on the plans for it? (Other than what is in the
> > wiki.)
>
> Not sure about the documentation, but the consensus was to use Java Mail
> abstraction and standard formats like maildir, mailbox under it. To some
> extent repository ideas for SMTP and NNTP are similar to maildir. SMTP and
> NNTP both store raw messages in single files.
> IMAP was tested by Darrell with inmemory(non persistent) repository but
> hasn't moved from there as far as I know.
>
> Everybody agrees we should converge to a repository and format
> asap. At the
> moment it is not too far apart at file system level but everything else is
> parallel.
> The key is moving code to standard repository API. The sooner we
> do this the
> better. If javamail proposal takes too long to build maybe we should just
> let it go away and use the current repository API/implementations as it is
> and move nntp to it.  thoughts.. ?

I have some thoughts, but they would impose a big structural overhaul of
James:
(I'm thinking more RDBMS centered then OO design/Java here...)

First off all we start with four different concepts:
- objects(files): These could store anything from an email, newsposting or
any other type of file. They could be stored with a MIME type
(message/rfc822, text/plain, iCalendar etc...)
- folders(store): These would be containers for objects. They could
represent a user inbox or other folder, a public folder/NNTP group. They are
ordered in a hierarchy, starting at a root object (parent set to itself)
- users: These are user accounts that are allowed to log in on any of the
servers services.
- directory(recipients): This would represent any type of recipient: users,
nntp groups, remote contacts, mailinglists. There would be a mechanisme to
allow for custom attributes to be stored.

I think that working with this abstraction, you can implement most mail,
new, calendering and other type of groupware services:

- NNTP: Can serve (part of) the folder hierarchy.
- IMAP4: Can theoretically serve the whole folder hierarchy, where the users
home directory is specified in a directory entry.
- POP3: Could serve the users (IMAP4) inbox or another folder, specified in
a directory entry.
- SMTP: Any incoming mail is matched against the directory for a valid
recipient and stores the email in the specified folder or sends it to the
mailinglist members defined in the directory.
- iCAP: Could use a set of folders to store the user calendars.
- LDAP: Should be able to serve the directory.

Pro's:
- flexible storage abstraction, allowing easy expansion for new services
- email addresses are not required to be bound to a user and vice versa
- objects and folders could be 'linked' using a many-to-many relation,
alling single instance storage accros the whole server

Con's:
- major James overhaul since almost the whole storage architecture has te be
rewritten, along with the configuration and probably the other services
- this architecture might create some extra overhead (extra database
lookups), degrading the overall performance
- somebody has to implement it :)

If there are questions left (there probably are...), I'll be happy to answer
them. It is very hard to describe the thing I have in my head in words. If
there is interest in this idea, I'll be happy to send a (My)SQL script that
would implement something like this.

Vincent de Lau
 vincent@delau.nl


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


Mime
View raw message