Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

CourseWork team:

  • Lydia Li - Samigo Lead, CWC->CW5 Assessment Migration, CW Classic, Stand-alone Syllabus developer
  • Jing Wei - CW Classic, CW Classic-Archive, CW5 Syllabus, Stand-Alone Syllabus developer
  • Daisy Flemming - Samigo, iTunes, CW5 Syllabus deveoper
  • Karen (Hui) Tsao - Samigo
  • Casey Dunn - Integration Lead developer
  • Annika Rogers - long time Stanford Contractor, Migration "anchors" and 1st content pass
  • Margaret Petit - QA Lead (UserX)
  • Laura Burchard - QA, Load, Build, Automated testing (UserX)
  • Jeff Vance - QA/Dev (very part time) Load, Automated testing, "SOPI", Python maven (Floats Around Looking For Work)
  • Julian Morley - sysadmin, very busy
  • Jackie Mai - Support and Marketing and Design (UserX)
  • Julie Mai - Support and Marketing and Design (UserX)
  • Marc Brierley - User X manager

and Makoto To guide them

Status:

We are running 2.3.x, with Course Management 2.3 / 2.4 integration.

We are planning on running 2.4 in Fall 2007, with legacy content migration of 1 year's worth of site data.

Stanford University's Academic Computing department has Sakai integration points of:

  • Authentication in production, excluding Shibboleth
    • WebAuth to Kerberos (K5), using Sakai container authentication in production
      • allows for quick sysadmin mods to .htaccess type files for security changes
      • basic Sakai container auth is a well known practice.
    • direct K5 auth SKrbLDAP in production
      • provides Auth for WebDav, for non-Apache/WebAuth deployments (such as my MacBook Pro)
      • the DAN comes from Sakai's bundled Kerberos UserDirectoryProvider (UDP)
    • LDAP lookup in UDP in production
      • maps LDAP attributes to Sakai user type, populates additional Sakai user properties
      • allows us to drop WebAuth Apache from our service stack, fewer moving parts
      • define LDAP attrs to pull in prop file
      • why?
        • Stanford users can have multiple email accounts. They don't have to use the one associated w/their Kerberos identity (foo@stanford.edu). Base accounts won't even have Stanford email services.
        • to map Stanford Workgroups to Sakai User type templates; this means custom user My Workspace pages based on the users affiliation to the University.
      • does K5 auth via keytab
    • Shibboleth
      • planned grabbing of REMOTE_USER and additional remote affiliation information from HTTP request, mapping to Sakai User Template types, stuffing into User properties.
        this is rather a simplistic view, and we'll probably have to be tricker, with call backs to the IDP or whatever it's called (wink)
        However, since this design has our SSO WebAuth in front, and another team is going to implement the WebAuth / Shibboleth hooks, I'm not going to worry about it. Identity and transience of Identity will be a common issue for all Stanford Shibbolized Sites.
  • Stanford Groups
    • AFS PTS groups, various needs
      • K5 remctl interface to existing enterprise API Spring 2007
    • Majordomo mailing list groups
      • K5 remctl interface to existing enterprise API Spring 2007
  • Bulk Load of Classes into Course Management API in production
      • on demand load of Instructors/Courses/Classes/Sections, digested into Course Management 2.3 tables
      • Quartz scheduled synchronization of Stanford CourseClass/Offering/Sections & all associated fleshy units
    • XML Feeds of Registry Course Information
      • custom doc format
        • membership
          • sunetid, name, university id, registry id, enrollment status
        • basic roles (instructor/student/TA)
        • cross listings
        • official sections
        • location, times
        • organizational ownership percentages
        • enrollment state (open, closed)
      • certificate based HTTPS transaction
      • ad hoc and scheduled
  • Integraiton with Legacy CMS (CourseWork)
    • bulk import of historical data Summer 07
      • extended roles (above, plus TA, Course Designer, course admin, department admin) partially implemented now
      • syllabus
      • schedule
        • Stanford, being a Quarter based school, has an easily re-usable "year to year" Class schedule tool. It's based on numbered weeks...
      • content, all types Spring 2007
        • content copyright state
        • content release vis course schedule
      • assessments, past grades
      • ad-hoc sections (very useful)
      • ad-hoc cross listings
  • Nagios in production
    • surface monitoring
    • transaction viability monitoring
  • CourseWork grade notification and logging abandoned
    • internal fatal errors to newgroups and pager lists
    • intrasystem 'touchpoint' failure alerts
    • logging of administrative activities
    • logging of authentication
  • Stanford Email services
    • play-fair in production
    • get spam filtering for inbound
  • Stanford news groups
    • use existing newsgroups Summer 07
    • needs remctl and roster info, no biggie now.
  • existing Stanford WWW
    • (not much to do here, external links. content management instruction is the issue here. the remctl APIs above will take care of the brute mechanics.)
  • Indigo Project (iTunes) Summer 07
    • secure rich media w/DRM\
    • currently in CWC, reviewing privacy concernes with Apple now.
  • Stanford Event Feed Spring 07
    • changes in SIS are paralleled with event postings to custom enterprise backplane (which is due for replacement)
    • changes in CourseWork-Sakai should publish to same backplane long term
  • No labels