Re: Fedora in Content Hosting - An Alternative

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.