An email dilemma?
First I want to thank the people at Astone for contributing this package. With respect to our deployment of Nuxeo this package couldn't have been released at a better time. THANK YOU to everyone involved.
As I work with this package I found and interesting dilemma:
The package takes an email and creates a Nuxeo email document in a nuxeo workspace. The package is able to take the email's attachments and place them as content in the Nuxeo email document type.
The package also, keeps a .msg copy of the original email and places it also into the Nuxeo email document; a good thing!
This is where the dilemma is: By wrapping the original email in a Nuxeo email container the original email is not available to anyone who tries to access the email using the WEBDAV interface using windows explorer. Since the webDAV interface looks like a standard directory on Windows (I haven't tried it on Linux, but I will) and the Nuxeo email is not a standard known document type (MIME type???); the directory structure looks empty to webDAV while from the Nuxeo GUI one can look at the emails attachments and original email.msg files.
We are using Nuxeo as a “transparent” Windows archive (and a lot more) for email filing as well as other documents that run our business.
There are operational ways around this but I would like to explore the best way to have both the Nuxeo email, with it's indexing of the email content and tracking, and transparent access to the archive from Windows applications.
Since I am new to CMIS is there a CMIS client solution that would solve this dilemma?
As always, thank you for any insight/comments you may have.
What about using the standard rfc822 format supported by Nuxeo (.eml/.mime) with mime type 'message/rfc822'? Plain text rfc822 messages can be readed by most of the mail clients and can be indexed by Nuxeo.
It shouldn't be very difficult to convert the proprietary and binary MAPI .msg format into the plaintext .eml format. A very basic start with .NET for the filter might be System.Net.Mail.
I don't know Astone's mail package, but if it uses CMIS to store document data I guess you can filter the email when it is made persistent using a CMIS content stream.
Nevertheless I think a smarter solution is it to transform the *.msg files on server side.
I did see the "server side" blog in response to one of my previous questions.
I agree, with the rfc822 solution being the best solution.