RE: Fedora in Content Hosting - An Alternative

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