Hi All,
Greetings !
I was a GSoC student in 2011 who had worked in implementing JavaScript UI
over DSpace REST API.
Integrating Hydra with DSpace over its REST API seemed quite interesting to
me, hence I explored a bit on the architecture of Hydra.
I observed the following (refer
https://wiki.duraspace.org/display/hydra/Hydra+Stack+-+The+Hierarchy+of+Promises#HydraStack-TheHierarchyofPromises-ApplicationLayer
):
- Hydra Heads are at Rails layer and thus are more end-user centric
- Providing DSpace repository to Hydra needs to be done at Application
layer
In the Application layer, we may do it in following ways (refer
https://wiki.duraspace.org/download/attachments/22022608/Hydra+Architecture+DiagramV2.jpg
):
- Implement Rubyspace and ActiveSpace ruby gems similar to Rubydora and
ActiveFedora using DSpace REST API and Ruby ActiveModel APIs and run Hydra
using Rubyspace and ActiveSpace over DSpace
- Implement a Fedora REST interface over DSpace REST API and plug it
between ActiveFedora and DSpace repository and things should probably work
Since the REST API may not be fully supporting all parts of Fedora REST
API, I would consider first alternative to be more feasible for GSoC
project.
Any further guidance on the scope and developer materials on ActiveModel
API would help me get better idea about the design.
Warm Regards,
On Wed, Feb 13, 2013 at 1:19 AM, Tim Donohue <[email protected]> wrote:
> Hi Peter,
>
> On 2/12/2013 12:47 PM, Peter Dietz wrote:
> > Perhaps if we had more wood behind fewer arrows. (That's Larry Page
> > speak for higher quality.)
> >
> > Call me crazy, but I would like to see (sanity check me please), a Hydra
> > Head with DSpace as the backend.
> >
> > This gives us a Ruby on Rails app that is a consumer of our REST API.
> >
> > Peter Dietz
>
> Although I like the idea of this as a project, I do want to caution that
> it might be too large for a Google Summer of Code.
>
> Obviously in GSoC, we'd be working with students (most of whom may not
> have direct experience with either DSpace or Hydra, unless we lucked out
> on a student who had heard of these projects). Plus we are limited to
> one student per project (per GSoC rules), and a student's project must
> be theirs & theirs alone (i.e. although they can collaborate with other
> developers/mentors, they need to have a scoped area of the project which
> only they are working on.)
>
> So, although I personally would also like to see someone do a "proof of
> concept" Hydra Head on a DSpace REST API (as I'm sure the Hydra folks
> would too), I worry that it may be too large of a project for a single
> student over a summer. Though maybe there'd be a way to scope it down
> and set better parameters around what we expect to be done over a summer.
>
> I'm not saying we couldn't still add it to the possible list of
> projects. I'm just saying, it might be hard to complete an entire Hydra
> Head on DSpace in one summer unless the student was exceptional (and had
> support from some exceptional mentors who know both Hydra & DSpace).
>
> - Tim
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
--
*Vibhaj Rajan*
*
**Computer Science & Engineering | (M. Tech. IDD) Part V | IIT (BHU)
Varanasi
*
*[email protected] | +91 92 35 312 784*
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
