jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Request for Jackrabbit Advice
Date Fri, 18 Nov 2005 08:07:10 GMT
On 11/17/05, Michael Wilson <mwilson@imageworks.com> wrote:
> 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.

the SimpleDbPersistenceManager (and its subclasses) have a configurable
attribute called 'externalBLOBs' controlling whether binary values should
be stored in the file system or in the db.

cheers
stefan

>
>
> 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.
>
> Mike
>
>
>
>
>
>

Mime
View raw message