Hello Ralf,
Thanks for your post. You raise a great question, and one which is probably
not unique to your institution.

An ability to support the spectrum of underlying storage systems and the
increasingly demanding requirements around datastream sizes and storage
scalability are both contributing factors to the architectural transition
we are seeing from Fedora 3 to Fedora 4. Developing an in-house
storage-layer solution is not an uncommon approach for addressing this
issue with Fedora 3. If doing so within the Fedora 3 context is or is not a
good idea likely depends on a number of considerations of which I will not
speculate here. There is certainly a wealth of experience across the
members of this mailing list that could help inform that decision.

However, I would like to reemphasize the fact that Fedora is a community
project that derives its success from the collaboration of a diverse
installation-base. Collaboration is not always easy, but working as a
community at the conceptual, architectural and technical levels is what
gives Fedora its strength.

For you, Ralf, or anyone who is considering developing an in-house
implementation to address a pain-point which is likely felt across other
institutions, I would suggest seriously considering applying your efforts
towards core Fedora development. I suspect you will find the final outcome
far exceeds what any one institution can achieve alone.

As for whether you should move forward with a custom Fedora 3 repository
project or start directly with Fedora 4, that largely depends on your
timeline. As I mentioned before, Fedora 4 is still working towards a beta
release. Putting effort towards custom Fedora 3 development with the
potential for further effort required to migrate off of the in-house
storage-layer implementation may or may not be recommended over adding
schedule into your project to forward the Fedora 4 effort.

Please let me know if you are interested in engaging directly with Fedora
development.
Regards,
Andrew



On Fri, Sep 27, 2013 at 2:03 AM, Ralf Claussnitzer <
[email protected]> wrote:

>  Hi Andrew,
>
> we are currently setting up a Fedora 3 repository. The main reason we
> choose Fedora over other systems is its flexibility at storing data
> streams. The problem we are facing is that due to the size (and legacy
> system dependencies) we simply can not just move all digital objects over
> to the new Fedora system. The plan (so far) is to develop a custom storage
> layer that maps our legacy systems storage into Fedora.
>
> So the questing is: Given Fedora 4 brings up a complete new storage
> system, does it at all make sense to put effort in developing Fedora 3
> storage layer components? Is this a good idea anyway?
>
> Best regards!
> Ralf
>
>
> On 09/26/2013 04:24 AM, Andrew Woods wrote:
>
> Hello Stefano,
> I would like to say that you should begin your project with Fedora 4.
> However, the fact is that on the one hand Fedora 4 is still working towards
> a beta release, and on the other, a very solid Fedora 3.7 has just been
> released.
>
>  If it is not already perfectly clear, one of Fedora 4's main priorities
> is to ensure a simple content and application upgrade process for Fedora 3
> installations to Fedora 4. Using Fedora 3 with Akubra will not be a barrier
> to subsequently upgrading to Fedora 4.
> Regards,
> Andrew
>
>
>
> On Wed, Sep 25, 2013 at 2:50 PM, Stefano Cossu <[email protected]> wrote:
>
>>  Hi Andrew,
>> Thanks for your clarification and your graph.
>>
>> Would then Akubra become redundant in this scenario?
>>
>> The main reason I am asking this is that I'm debating whether to start a
>> new project with Fedora 3 or 4 (and storage is one of the main points in my
>> choice). If I start with F3 and Akubra, I am wondering if when I upgrade to
>> F4 at some point in time I would have a harder time transitioning to
>> Infinispan with Akubra in the way.
>>
>> Thank you, and thanks for keeping the Fedora Futures Wiki up to date!
>>  Stefano Cossu
>> Director of Application Services, Collections
>>
>> The Art Institute of Chicago
>> 116 S. Michigan Ave.
>> Chicago, IL 60603
>>  312-499-4026
>>
>>
>>   On 9/25/13 12:27 PM, Andrew Woods wrote:
>>
>> Hello Stefano,
>> Thanks for probing into Fedora 4. It may be worth clarifying the fact
>> that Fedora 4 represents an architectural shift from a custom-developed,
>> ten-year-old software application to a new software stack as depicted in
>> the attached document. You are correct in drawing an analogy between the
>> storage layer options of Fedora 3 and the role of Infinispan in Fedora 4.
>>
>>  Fedora 4 adds the preservation and access sensibilities that are
>> important to the Fedora community to the vanilla ModeShape [1] JCR
>> implementation. Optimizing for the ability to cluster and for performance,
>> the recommended storage configuration of ModeShape is to layer over
>> Infinispan [2]. Infinispan, itself, has a number of persistence store
>> options available including simple filesystem and a range of databases.
>>
>>  Based on a variety of Fedora installation profiles and use cases, we
>> will be providing Fedora4/ModeShape/Infinispan configuration "recipes"
>> which will take the guess-work out of how to get to an efficient
>> configuration of your repository.
>>
>>  Regards,
>> Andrew
>>
>>  [1] https://docs.jboss.org/author/display/MODE/Home
>> [2] http://infinispan.org/docs/5.3.x/user_guide/user_guide.html
>>
>>
>> On Wed, Sep 25, 2013 at 11:18 AM, Stefano Cossu <[email protected]> wrote:
>>
>>> Hi there,
>>> I have heard a lot of buzz around the new storage layer based on
>>> Modeshape and Infinispan in Fedora 4.
>>>
>>> Not being very confident with Fedora's inner workings, nor with JCR
>>> itself, I'm wondering how this is related to the Fedora 3.x legacy
>>> filesystem and Akubra storage engines. Is Modeshape/Infinispan meant to
>>> be an alternative or replacement for these engines? Or do they work
>>> alongside with different purposes?
>>>
>>> Some explanation would be appreciated.
>>>
>>> Thanks,
>>> --
>>>
>>> Stefano Cossu
>>> Director of Application Services, Collections
>>>
>>> The Art Institute of Chicago
>>> 116 S. Michigan Ave.
>>> Chicago, IL 60603
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from
>>> the latest Intel processors and coprocessors. See abstracts and register
>>> >
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Fedora-commons-users mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register 
>> >http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Fedora-commons-users mailing 
>> [email protected]https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Fedora-commons-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>
>>
>
> --
> Ralf Claußnitzer
> Abteilung Informationstechnologie - Referat Digitale Bibliothek
>
> Sächsische Landesbibliothek - Staats- und Universitätsbibliothek Dresden 
> (SLUB)
> Zellescher Weg 18
> 01054 Dresden
> Tel.:  +49 (351) 4677-228
> Fax.: +49 (351) 4677-711http://www.slub-dresden.de
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Fedora-commons-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users

Reply via email to