On 11/17/05, Michael Wilson <[EMAIL PROTECTED]> 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 > > > > > >
