Re: Fedora in Content Hosting - An Alternative

Contributed at
http://bugs.sakaiproject.org/jira/browse/SAK-4457

Mark has created a confluence page, which I will add to shortly.
Ian


Knoop, Peter wrote:
> > -----Original Message-----
> > From: Ian Boston [mailto:ian@xxxxxxxxxxxxxxx]
> > Sent: Thursday, April 27, 2006 4:08 PM
> > To: markjnorton@xxxxxxxxxxxxx
> > Cc: sakai-dev
> > Subject: Re: Fedora in Content Hosting - An Alternative
> >
> >
> > I could put it into contrib, but its really a patch......
> >
> > Does sakai have an official Patch Queue ?
>
> Our take on this practice for now is the "Contributed Patch" issue type
> in Jira.  As time permits these are reviewed and integrated into Sakai
> as appropriate; however, as you note below, it's the resources for this
> a very, very limited right now.  That situation will hopefully begin to
> improve as more folks volunteer and get involved with the long-term
> development of Sakai.
>
> > In the past I've sent some to Glenn, but its not really fair to bury
> one
> > person under a mountain of patches.
> >
> > I'd be quite happy to document it, and how to write and inject a
> plugin
> > in confluence, if someone can suggest where?
>
> You could stick the documentation with the Jira Contributed Patch for
> starters.  We can always move it to a better place later on.
>
> -peter
>
> > Mark Norton wrote:
> > > Very interesting, Ian.  Have you posted this to contrib?  Any
> > > documentation or notes?  This sounds like a very nice addition to
> the
> > CHS.
> > > - Mark Norton
> > >
> > > Ian Boston wrote:
> > >
> > > > We have implemented something similar in 2.1.1 and are just porting
> to
> > > > 2.1.2 and 2.2
> > > >
> > > > Its a plugin into ContentHostingService that enables an
> implementing
> > > > class, once it has registered itself with the ContentHostingService
> to
> > > > be consulted if it 'owns' a node in the content hosting tree. Once
> it
> > > > 'owns' the node, it takes responsibility for providing
> > > > ContentResources for that node and all child nodes.
> > > >
> > > > We have used this to implement an IMS-CP plugin, that 'plays'
> IMS-CP
> > > > files
> > > >
> > > > but you could just as easily use it to 'mount' a repository inside
> the
> > > > ContentHostingService at an arbitrary position.
> > > >
> > > > If the resource is read-only, or cant be accessed via DAV, then it
> is
> > > > the responsibility of the plugin to act accordingly. (ie, not
> return
> > > > the content)
> > > >
> > > > We are also looking at wring a plugin 'interprets' an XML file
> loaded
> > > > into resources to invoke a UI. The XML file containing the
> > > > configuration of the UI.
> > > >
> > > > With Fedora, that XML file might be the connection settings to the
> > > > repository.
> > > >
> > > > Since the plugin patch is small (<50 lines), and the plugins can be
> > > > implemented inside webapps (ie reloadable), I am hoping that it
> will
> > > > be useful and can be included in the BaseContentHostingService for
> 2.2.
> > > > If it isnt, we will maintain it as a patch as it as we are going to
> be
> > > > running it in production in July.
> > > >
> > > > Ian
> > > >
> > > >
> > > > Mark Norton wrote:
> > > >
> > > > > Having said that re-writing ContentHosting would be a large
> > > > > undertaking, there is another approach that could be considered.
> > > > >
> > > > > Suppose we were to extend the existing ContentHosting service,
> > > > > specifically the ContentCollection class such that it serves as a
> > > > > gateway to a repository.  It would need to represent the protocol
> to
> > > > > be used (Fedora, SRA, JSTOR, whatever) and likely include at least
> > > > > some support for digital rights management.
> > > > >
> > > > > A simple idea with a lot of consequences, both easy and hard.  On
> the
> > > > > plus side, repository-based collections could either be tied to a
> > > > > search pattern on the repository,or tied to a specific remote
> > > > > collection (including the root).  Done right, it would integrate
> > > > > seamlessly into existing Sakai tools, such as the ResourceTool,
> etc.
> > > > > On the minus side, ContentResource might also be affected, since
> the
> > > > > tools would list content that is no longer directly accesible via
> the
> > > > > current implementation.  WebDAV integration might also be
> challenging.
> > > > > In the intial stages, this would have to be an optional feature
> that
> > > > > could be enabled or disabled since I don't think that complete
> > > > > integration would come quickly.  Still, one could have an instance
> of
> > > > > the ResourceTool tied to a specific repository (not mixed) that
> could
> > > > > be billed as not supporting WebDAV or other regular content
> hosting
> > > > > features.
> > > > >
> > > > > - Mark Norton
> > > > >
> > > > > ----------------------
> > > > > 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.
> > > ----------------------
> > > 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.
> > ----------------------
> > 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.
>
> ----------------------
> 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.

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