Chris, Thanks for your comments. I will run these tests as soon as possible.
My reason to experiment this solution is that there are current and future data manipulation tools that needs to "see" the file system, rather than dynamic streams from disseminators. The data are still curated via Fedora, and other tools' access is read-only. If anyone can convince me this is a bad, or good approach, I'd appreciate it and be happy to alter my direction. Thanks, -Jerry > -----Original Message----- > From: cwil...@gmail.com [mailto:cwil...@gmail.com] On Behalf > Of Chris Wilper > Sent: Wednesday, September 29, 2010 12:25 PM > To: Pan, Jerry Yun > Cc: fedora-commons-users@lists.sourceforge.net > Subject: Re: [fcrepo-user] FW: Low-level storage change questions > > Hi Jerry, > > On Wed, Sep 29, 2010 at 10:41 AM, Pan, Jerry Yun > <p...@ornl.gov> wrote: > > [..] > > I experimented an approach in which I installed a custom > PathAlgorithm > > and a ILowlevelStorage to change the default timestamp based path > > algorithm, into using a PID namespace algorithm, and also > changed code > > in DefaultDOManager.java, ILowLevelStorage.java to allow > MIME type be > > used in the file name if MIME type is given. The changed code and > > fedora server appear to work for me fine. It would also seem to be > > minimally intrusive to the base code, for the added code, although > > DefaultDOManager.java change is somewhat intrusive. > > > > I am not sure the consequence of this change to the > integrity to the > > system (I am aware the obvious security by-pass). > > Right...if you provide out-of-band access to the low level > storage files, that's your business, as long as you're aware > that Fedora is not going to provide the access controls it > normally does when you go through the APIs. > > > Is there any unit test I need to > > setup and run against, to ensure nothing is broken? > > There's a set of integration/system tests that I would > recommend running, which comes with the source code. The > README file in the root of the source tree explains how to > run them. I would at least recommend running the "configB" > tests -- this is a test suite that executes against a live > Fedora repository instance. > > > Anything else I need to watch out for? > > Since you made a local change to DefaultDOManager to > ILowLevelStore to allow the MIME type to be used as part of > the path algorithm, you should know that it's going to be > harder for you to upgrade to future releases (you'll have to > forward-port your changes for your custom version of Fedora), > as the released versions of the class+interface are going to > be different than yours, and will continue to change over time. > > > A related question is on Akubra, which I saw from the code > and heard > > from other people/presentations, how is that related to what I do? > > There are parallel classes named Akubra** to the > LowlevelStorage.java > > and LowlevelStorageModule.java, I am not sure how Akubra is > or should > > be used for my case. > > There's an Akubra-based implementation of the ILowlevelStore > interface. It just stores blobs and is generally not aware > of metadata about those files. Like the ILowlevelStore > interface, Akubra is intended to be pluggable, so you can > provide your own implementations underneath the API. The one > that comes with Fedora out of box is called akubra-fs, and > behaves similarly to the legacy LowlevelStorageModule -- it > stores files on the local filesystem. > > Normally, I would recommend doing an Akubra-based > implementation of your customizations. However, one thing > that complicates the issue is that you want to use the MIME > type to allocate the path -- and although it can be done, > there is currently no Akubra implementation that can use > metadata like that in order to allocate file paths, so it > would mean writing your own, which is aware of something we > call "hints" in the Akubra API. I'd be happy to advise more > on that if you're interested -- please write to the > akubra-dev list if so. List info is here: > http://groups.google.com/group/akubra-dev > > Long-term (Fedora 4.0+, which may be at least a year away), > we're looking at an additional, but higher storage > abstraction in Fedora that would more directly allow you to > make storage decisions based on the MIME type of the > datastream as well as a variety of other data. > This is called High Level Storage, and the work is being described > here: https://wiki.duraspace.org/display/FCREPO/High+Level+Storage > > Thanks, > Chris > ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
