Jukka Zitting ha scritto: > 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.
"email archival" sounded too generic to me: our jdbc and mime-file based email repositories are already used as "email archival" by someone but they never deserved a standalone product. >> 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. This answer perfectly satisfies my need :-) Let's make it work as a JAMES Server component, THEN, if we'll have created something working also standalone we'll discuss and vote for a specific sub-product/sub-project. Thank you, Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
