Re: Seeking status of 'Rep API' and 'JSR-170' shim from "Sakai Repository API Design"

Peter,

I echo Mark's comments - this is not something to do quick and dirty  
and expect to have something runnable or releasable.

ContentHosting is one of the "backbones" of Sakai and supports  
WebDav, the AccessServlet, the WebServlet, Resources Tool,  
Presentation Tool, interoperates closely with Sakai's Authorization  
model, generates well-formed Sakai notifications, and real-time  
events,  and is cluster aware and on and on.

It is pretty optimistic to expect that after 12 weeks that you would  
have an alternate implementation that could run in even a small  
production environment and support all of the tools and uses of  
ContentHosting.

However, at the end of 12 weeks whoever gave this a solid try *would*  
have learned a ton about how stuff is put together in Sakai and would  
be able to contribute to a long term effort to develop a truly  
production capable solution.

One of the problems we face in Sakai is folks who want to work on a  
very complex piece of Sakai for a short-while, expect the code to  
ship in the next release of Sakai, and then expect to walk away from  
the project and leave someone else performance tune their code and to  
fix the bugs in their code and support their code in all of the  
production implementations of Sakai going forward.

What Sakai really needs is long-term commitments from people who are  
willing to stick with software elements and serve the communities  
needs over a multi-year period.

All those caveats aside, your use case is a very important use case  
and something that is clearly on our long-term roadmap.   The right  
way to approach this is not to try to completely re-write  
ContentHosting, but instead to design and develop a plugin pattern  
that allows Content Hosting to precisely outsource things like Blob  
storage and Metadata storage with simpler APIs than ContentHosting  
and a very clean and simple API contract.  Then we can write these  
plugins for things like Fedora, JSR-170, DSpace, iTunes, etc etc.

A summer of code could very naturally explore this and come up some  
ideas and proposals as to how to do this properly.

/Chuck

On Apr 26, 2006, at 3:57 PM, Peter Murray wrote:

> Still, based on instinct alone if nothing else, getting something
> up-and-running sounds like a 12-week project.  It'd be an intense 12
> weeks, though.  Sakai-Dev'ers -- if you or a student you know would be
> interested in getting paid to work on this during the summer, please
> take a look at the Google Summer of Code program.
>
>
> Peter

[see attachment: "message0.html", size: 4194 bytes]


Attachments:

message0.html
http://collab.sakaiproject.org/access/content/attachment/4d9ea59e-5480-400f-801e-a5edf1b0f89b/message0.html

----------------------
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.