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
