Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Peter Murray <peter <at> OhioLINK.edu>
Subject: Seeking status of 'Rep API' and 'JSR-170' shim from "Sakai Repository API Design"
Newsgroups: gmane.comp.cms.sakai.devel
Date: Wednesday 26th April 2006 13:58:56 UTC (over 10 years ago)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm still working my way around "Sakai-land" (if you will) seeking the
best way to integrate a Fedora-based content repository with Sakai.
I've had great conversations with Beth Kirschner from UMich and Ben
Brophy from MIT about their efforts.  Our desires differ from those
projects, though, in that we seek to make Fedora /the/ content
repository for Sakai as opposed to a Sakai search/browse/retrieve/edit
tool for Fedora.

I found a year-old document on Confluence with the title "Sakai
Repository API Design"
(http://bugs.sakaiproject.org/confluence/download/attachments/2852/repository-design-v1.doc?version=1).
It offers two integration points for the content repository:  a "Rep
API" and a "JSR-170 API".  I can find reference to JSR-170 as
http://bugs.sakaiproject.org/jira/browse/REQ-210
but not reference to
the Repository API.  Help in navigating the Confluence and Collab sites
would be most welcome.

My thinking on the integration has evolved somewhat over the past few
weeks (starting from the naive notion that providing an implementation
for legacy/Entity.java class would be all that is required) to include
these possibilities:

* If the "Sakai Repository API Design" document of March 22, 2005,
remains accurate, create a JSR-170 shim for Fedora (although, as
the author of that document noted, "[Apache] Slide [a JSR-170
implementation] will not have explicit support for the Sakai
organization structure...needed [for] efficient interrogation
of access permissions..."  Bridging access management structures
will be a challenge, although I'm hoping (perhaps, again, naively
so) that n-tier Shibboleth will help along these lines.

* A Fedora shim that mimics the "Enterprise Repository Implementation"
in the design document.

* Or, most radically and improbable, an implementation of Hibernate
over Fedora -- e.g., a object-relational-object storage structure.

I'd like to try to firm up the possibilities within the next few days so
as to include them on OhioLINK's Google Summer of Code idea list for
developing proofs-of-concepts (if not actual robust implementations).
(That list may have to include a suggestion for the JSR-170-to-Sakai
shim, if that doesn't already exist...and judging from the Jira issue it
doesn't.)  Students will begin submitting applications on Monday, so it
would be best if I can get it described by Friday.


Thoughts?

Peter
- --
Peter Murray                       http://www.pandc.org/peter/work/
Assistant Director, Multimedia Systems  tel:+1-614-728-3600;ext=338
OhioLINK: the Ohio Library and Information Network   Columbus, Ohio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFET3yf4+t4qSfPIHIRAtPQAJwIlAXVXIhWSHkhl0aR9tsu8pQSqACgpyLg
w9+mMjMhPOI8SBaGe+brE2w=
=OlgL
-----END PGP SIGNATURE-----

----------------------
This automatic notification message was sent by Sakai Collab (http://collab.sakaiproject.org/portal)
from the DG: Development site.
You can modify how you receive notifications at My Workspace > Preferences.
 
CD: 4ms