Can you make a rationale about a standalone product regarding JCR and
Mail but not involving JAMES Server ?
What exactly should such a component to?
There's a *strong* need in many organizations to archive *all* their
email in an easily searchable and integrateable repository. Currently
many of the major content repository vendors are getting a large part
of their revenue from selling such email archives.
Such an archive is typically added as an extra component that is just
fed by whatever email server the organization is using. Typically the
email server just has a catchall forwarder that copies all in- and
outgoing messages to such an archive.
Indeed. Mail handling as "documents" is a very important requirement in most (big) DMSes(Document
Management Systems) these days, and it's also not easy to implement.
The problem I see however is that most big DMSes *don't* use JCR because it's slow when it comes to
such big amount of documents (it's nice nice in theory but not in practice).
My experience is that if a (JCR) solution for mail archive wants to be usable to the potential users
(much more than is JCR to CMSes and DMSes) performance should be the first and most important feature.
just my 2 cents,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
