Hi, On 5/5/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
