On Thu, Jan 29, 2009 at 5:30 PM, Charles Earl <[email protected]> wrote: > I'm evaluating CMS and versioning systems for the backend of a SaaS > I'm developing for digital media production workflow. Example content > is from media production suites such as Adobe After > Effects/Premier: video, compositions, etc. So some ability to also > track possible binary diffs in binary data (video) as well as metadata > (e.g. modifications to effects applied in a composition, timeline > annotations, etc.). > - Is this appropriate for jackrabbit?
With JCR observation, you can easily handle any changes to metadata or binary content in the repository. JCR allows you to version your content easily, albeit things like diffing and merging of (binary) content is not part of JCR. > Are there similar efforts built on top of jackrabbit? Day Software has an enterprise CMS and digital asset management product on top of Jackrabbit (using the commercial CRX repository that is based on Jackrabbit) [1]. > - Do you foresee any performance challenges? Using the file DataStore is really fast, since it basically streams directly to the disk and since the datastore entries are never modified, it doesn't have any rewritings. Entries are also stored by their md5 hash, so if you have your 2GB video file twice in the repository, the datastore would contain it only once. > I'd also like the object storage to be in S3/Amazon BlockStore or > similar remote stores. Someone already committed an S3 DataStore implementation for Jackrabbit, see [2] and [3]. DataStore is the persistence abstraction in Jackrabbit that stores binary streams. I once tried to write a Persistence Manager that works with S3 [4], but the PM is too fine-granular for such a high-latency storage implementation (the PM is the main persistence interface in Jackrabbit that stores all nodes and properties). [1] http://www.day.com [2] http://markmail.org/message/iny24qxsieutfzeq [3] https://issues.apache.org/jira/browse/JCR-1724 [4] http://issues.apache.org/jira/browse/JCR-1509 Regards, Alex -- Alexander Klimetschek [email protected]
