...
a. user's space
Create a .sakai directory within the user's AFS space that the Sakai user account has access to write to. User's will not be allowed to browse this directory, since it is only pertinent to Sakai. Also add a sakai instance directory to the path which only the specific instance (e.g. smartsite or cere) would be able to write to.
b. course space
Utilize This would fall under a root sakai directory, and utilize University of Michigan's current mapping (see above for format of file path ) of logic for setting course content file path, and to avoid name collisions.
c. projects/research space
Sakai has many types of sites, and each install can configure these. There will be sites related to projects and research that can be expected. User's space, and possibly another space in AFS, will be utilized for these types of sites. Content stored in user's AFS space will count against the user's AFS quota, specifically the user who owns the site.
A couple of alternatives to project sites can be defined.
1) For each personal project site, store the content in the user's space. For each institutional project site, store content in the AFS project space. This would allow us to utilize AFS quotas on both user's and project space. The metadata in the Sakai database would point to the given AFS paths above.
2) The same pattern as #1, except that sim links are written in the institutional project space directory for personal projects. Institutional project content would be written the same way as above. This option would allow us the flexibility of not having to update the Sakai database in the future (links would stay the same), and also allow us to quickly find dead links (e.g. user's who may have left the institution).
...
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.
...
- 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
- Determine if bodypath exists via ContentHostingService. In order to determine existence, find:
- 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 - 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.
- 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
...