jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Wilson" <mwil...@imageworks.com>
Subject Request for Jackrabbit Advice
Date Thu, 17 Nov 2005 19:16:07 GMT
My company is currently searching for a suitable replacement for our
existing content management system.  Unlike many CMS's ours
predominantly handles large binary assets (images/mpeg) and has some
rather hefty scalability and security requirements.  

I have a laundry list of requirements and an even longer list of
questions but I didn't want to raise the noise floor of this forum so I
was hoping that someone on this list, if they are so inclined, would
contact me via my e-mail address to talk about our requirements and if
Jackrabbit might be a good fit.  Or perhaps there is a different mailing
list I should subscribe to and if so I apologize for raising these
issues here.

For the benefit of the mailing list though here are my questions in case
anyone would find these issues of value to be discussed here:

1) Is a hybridized data store possible with Jackrabbit?  
  By this I mean the binary assets are stored on disk and the metadata
is stored in a RDBMS.  Due to the size of the assets we work with,
storage in a DB would be impractical but we do require the scalability
of a RDBMS for searching and reporting on metadata due the # of assets
we track and the responsiveness required for searches.

2) Is there a notion of proxy representation in Jackrabbit and methods
to work with all related "children" of an asset?  

  By this I mean currently when we check an asset into our repository it
is thumbnailed at various proxy resolutions (JPEG only).  These
thumbnails in turn are now assets that must maintain a "relationship"
with their parent.  If the parent is deleted, these thumbs need to be
deleted also.  Any basic CRUD on the parent asset would need to modify
these "child" assets appropriately although versioning isn't required.
The same could be said of watermarked images created from these assets.

In some cases the related child assets have child assets of their own.
For example when checking an image (approx 100MB), it would most likely
be proxied at .5K, 1K, and 2K resolutions.  Additionally, the proxies
(thumbs) would also all get watermarked and potentially the original
might also get a full resolution watermark.  How might this be handled
by Jackrabbit?  Do you think issue could be resolved with references
and/or multiple workspaces?

3) Is the MIME type handlers framework extensible?  

  We frequently work with image formats and movie formats that are
novel.  This includes Cineon files and proprietary AVI formats that
imbed security information in them.  How much work would it be to plug
these types of assets into the jackrabbit and still be able to generate
thumbnails/watermarks/etc on checkin as mentioned above?  Generation of
post checkin operations would probably also require a callback mechanism
of some sort so that based on MIME type certain workflow could be based
on MIME type such as the type of thumbs generated, type of watermark,
e-mail to appropriate groups, and other workflow-like operations.

4) How would you recommend handling alternate taxonomic representations
of asset trees in Jackrabbit?

  It is rare, even on checkin, due to security requirements, that our
users ever know where their assets are physically located within our
storage infrastructure.  On ingestion into our current CMS the assets
are marked-up with multiple taxonomies (we call it "tagging") that cause
the asset (or it's proxies and watermarked copies) to appear at various
locations in a virtual asset tree based on the taxonomic information.
Basically, you can find the asset at many locations in the virtual tree
that is constructed for the users to work with the assets in the GUI's
that they use.  

Would you recommend using namespaces, references, and/or multiple
workspaces?  It seems possible from reading the JSR-170 docs but I'm not
sure which way would be best.  

6) Can security be handled at the tree branch level with delegated
security managers?
  One of the reasons we are thinking about moving off of our current CMS
solution is that it's security system isn't as granular as we require
and it is causing a great deal of maintenance overhead.  We need a
highly granular security system that can be hooked into LDAP (I'm pretty
sure you can already do this).  What I haven't been able to figure out
from the JSR docs though is how I might delegate responsibility for
portions of the asset tree to other individuals, if this is possible
currently, or even if this is the appropriate level of the technology
stack to talk about such issues; possibly they would be handled
somewhere else.

7) When is Jackrabbit slated for 1.0 release?  

So, if anyone out there cares to answer these questions here or
privately via my e-mail address I would be most appreciative.  I'm
currently coding up some performance cases using Jackrabbit, loading a
few thousand images with metadata, and it seems to be pretty solid.  I
personally would like to use the product but the questions above are
beyond my current understanding of the product so I had hoped to find
some answers here.  Thanks for any information you can provide.


View raw message