james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: JCR back-end
Date Sat, 05 May 2007 13:23:04 GMT
Hi,

On 5/5/07, Stefano Bagnara <apache@bago.org> wrote:
> My concerns where specific to a "product based on JCR, hosted
> on JAMES project, not related to JAMES Server".

Note that the use case I described (email archival) was an answer to
your question about a potential standalone need for similar tools that
we're going to write for James in the james-jcr sandbox. I'm not
proposing that we actually implement such an application *within*
James, but an external project might well be interested in reusing the
content model and generic import and access tools that we'll implement
for James.

Basically the question of whether the code should be in
james/server/sandbox or james/sandbox. For now I'm most interested in
targeting just the James server, but if the result is successful I'm
quite sure that there will be people who'd like to use the same
content model and supporting code also for other email environments.

Perhaps the optimal solution would be to have one generic component
that depends only on things like mime4j or javamail and the JCR API
and another component that contains the James-specific mailet and
other bindings. But I guess it's easiest to start with just a single
sandbox component for now and separate things when the code matures.

> Even after reading your message I don't fully understand what you are
> trying to describe.
>
> Is it a JCR client (GUI) specific to Email? Is it a library?
>
> Let's call it MCR (mail content repository): how would you describe this
> "MCR" ? A library that allow you to do THIS, a server product exposing
> this N services over XXX protocol. Is it instead a library that wrap JCR
> to make it more "email" oriented?

The email archival use case I described would store all email in a
content repositor using the generic tools and content model from the
james-jcr component that we're about to implement. On top of that an
archive application would typically provide a (web) user interface for
querying the email archives for various purposes, most notably to find
all correspondence that's relevant to a given audit or lawsuit.

The part that we'd implement in James is just the email to JCR mapping
that we'll need in any case for using a JCR store within the James
server.

BR,

Jukka Zitting

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


Mime
View raw message