Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. How do we integrate Sakai's resources and our current AFS file system?
    Answer: via replacing ContentHostingService with our own implementation for AFS storage. The current ContentHostingService, backed by DbContentService provides minimal file storage capability
  2. When user's create worksites, how does this get mapped?
    Answer:
    For user worksites, those would resolve to their current afs home mapping scheme (e.g. home/sn/samerson)
    For other worksites, the /afs/ root will be used as a starting point to store content. Project sites will have 2 types (user project sites, and institutional project sites), and course sites will be stored via /TermCode/CRN/Sakai instance structure. See AFS File Mapping documentation for more details.
  1. What location does it will content get mapped to?
    Answer: /afs/ as root path for now, and according to be determined at a later point when to split this pathing up..what type of site. If this is a user workspace, the home cell will be referenced. If this is a course site, then content will be mapped under CRN per given instance. For project sites, if they are user project sites they will be mapped to user home space, according to the ownership of the project (e.g. creator). For other sites, including project sites used for institutional purposes, they will be mapped to another designated area in the content system (to be determined)
    1. Do course type of worksites get stored in existing AFS CourseManagement space?
      Answer: Yes, this will get saved in the existing AFS structure, however each instance of Sakai (e.g. SmartSite, CERE) will be able to write to the content appropriately.
    1. Where do project/research/ or any other non-user and non-course Sakai sites get stored?
      Answer: under the /afs/ root path, but we need to determine a volume and/or whether or not the site name resolves to anything meaningful over time.

How Sakai stores content

Current Sakai architecture supports storing course and user content both inside/outside of a database. The content path can be mapped to any given path one gives it in the sakai.properties configuration file:

ref: http://bugs.sakaiproject.org/confluence/display/FAQ/2.2.7.1+Configuration

...

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.

Some Implementation details

The default registered service that handles content in Sakai is the DbContentService, which extends the BaseContentHostingService. A modification to the path generation in the DbContentService will allow the path to be configured for proper content storage in AFS. Creating a UCDavisContentService, which extends the functionality of the DbContentService, will enable custom configurations and "overrides" of methods which establish the file path used to store content. There are several considerations for this to be handled properly:

1. The site type must be determined, so the user's space may be used or that of CourseManagement.
This is currently in a somewhat working state, the only question is the project site types, and where to map them.

2. The user's quota should be checked prior to storage?
Needs to be implemented, and should be implemented at a point where files are saved.

3. The path must be customizable
Needs to be implemented. Currently, this customization can be implemented by overriding the bodyPath method in the DbContentService. This can later be passed in, via parameterization, to a n existing shell/perl script. There are some advantages and disadvantages of each method, and error handling is one of them.

4. Error handling considerations
The content hosting implementation must be able to handle file write exceptions appropriately. File read exceptions should not occur, as they should be handled internally by Sakai (Java) exception handling methods. If there is a file write error, they may be Quota extension errors, AFS downtime errors, or others. The ability to trap these type of errors and respond to them well, which the current CM system (MyUCDavis) does not handle, is crucial.

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

...