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 16 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
    • direct K5 auth SKrbLDAP_ in production
      • provides Auth to WebDav
      • based on Sakai 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
      • need same LDAP attr list property 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.
        • 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.
  • Groups
    • AFS PTS groups, various needs
      • K5 remctl interface to existing enterprise API Spring 2007
    • Course Membership Groups
      • needs more investigation Not sure the existing enterprise offering can bear the load of ad-hoc Sakai workgroups and not poison the experience of "super group administrators" it can't
    • Majordomo mailing list groups
      • K5 remctl interface to existing enterprise API
  • 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
    • 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
    • New Access to Peoplesoft (axcess) TA information!
  • 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
      • content, all types
        • content copyright state
        • content release vis course schedule
      • assessments, past grades
      • ad-hoc sections (very useful)
      • ad-hoc cross listings
  • Nagios
    • surface monitoring
    • transaction viability monitoring
  • CourseWork grade notification and logging
    • internal fatal errors to newgroups and pager lists
    • intrasystem 'touchpoint' failure alerts
    • logging of administrative activities
    • logging of authentication
  • Stanford Email services
    • play-fair
    • get spam filtering for inbound
    • use existing newsgroups???
  • Stanford news groups
  • 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