Page Comparison

...

5. Script language considerations
The current script that handles volume create, quota extension, etc. is a Korn shell script. We can choose to modify this existing script, however there are alternative possibilities of using Perl (e.g. AFS Perl), or AFS Java (e.g. openAFS APIs). The latter two (Perl,Java) are preferred, and Java most likely because the existing code base for Sakai is developed in Java, and this would minimize future maintenance issues. Also, using Java APIs and JNI would allow flexibility of getting back stronger error messages from AFS Errors.

A preliminary UCDavisDbContentService file is attached, which will replace the DbContentService as the registered service for storing content using Spring injection. This is a Sakai 2.1 example.

...

1. Determine bodypath for file storage, from ContentHostingService (e.g. append instance name, etc.)
   • Determine if bodypath exists via ContentHostingService. In order to determine existence, find:
     • Site type from a Sakai reference object (that ContentHostingService uses) if site type is:
     • Depending upon which type of site, find the appropriate volume relative to the bodypath that should be created
     • Determine userid from reference path (e.g. /content/user), instance, or other pertinent information from reference depending on site type (e.g. siteid, etc)
   • else if bodypath doesn't exist.. try to run volume create script based on volume previously determined
2. Save file given by ContentHostingService, and run quota extension check against current size of resource (e.g. byte length) vs. volume quota
   **If volume quota gt resource bytes, store content. Else increase quota by a factor of x
3. Handle errors (checked exceptions) at the Java level via: AFS errors either bubble up from shell/perl script to Java level, or determined by Java OpenAFS APIs.
4. If errors, log errors and either try again (e.g. quota extend), or fail and throw exception (e.g. AFS down). No logging written if no errors captured

...