2006-04-05 Agenda and Notes

Owned by Former user (Deleted)
Last updated: Apr 07, 2006 by Former user (Deleted)Version comment
4 min read

Meeting with Glenn @ Foothill college
Agenda:

9:30 Call in to Stanford conference line (Daisy, Duffy and possibly others will be on the line)
9:45 Review CM API and impl
10:15 Review LmsMappingService concept, API, and impl
10:45 Review CmGroupProvider impl
11:15 Discuss deliverables for 2.2
12:00 Lunch
12:30 Discuss Gradebook requirements dependent on CM and related infrastructure (LmsMappingService, CmGroupProvider, etc)
1:30 Discuss svn locations and modules for CM, LmsMappingService, and CmGroupProvider code.
3:00 Wrap-up

Notes:

Attendees: Glenn, Josh, Ray, Duffy, Daisy, Lydia

Glenn first went over his ideas on replacing static covers and reorganizing legacy code.

Josh gave an overview of the CM project:
/CM, Data Model, HibernateImpl, Browser, Web services impl

CM: Enterprise data is external to Sakai. Sakai has read only access to enterprise data.
In CM objects are simple, don't reference each other, always asks the Service object for things. The Service object does hibernate impl (so called Anti-pattern: Anemic Domain Model)
CM api only has getters (Ray mentioned one exception might be submitting grades back to EIS)

Glenn: what part of enterprise is CM concerned about ( for example: user identity, finance... are out of scope, )
Josh: CM has CourseSet, which might contain dept, school, group in dept... CourseoOffering can be in more than one CourseSet, Courses, enrollment, membership, credit, grades..etc

LmsMappingService:
maps entities in CM to sites/groups in Sakai. Has api and impl, read/write, can also expose thru web services,
i.e. Sakai site can be mapped to EnrollmentSet 1, Set 2.

Course site admin tool:
Cm read /write
Cm (read only)
(Will know more once mockup is ready by may 1st)

Glenn: Can the tool's scope include site creation?
Ray/Josh: yes. CM tool should include site creation.

Site ref id= authz group id

Daisy: at Stanford, student enterprise data, plus form(dept. admin fills out) information, both get fed into cm.
Josh/Ray: LmsMappingService thinks it's coming from enterprise. (doesn't matter if it's hybrid)

Josh: read/write API, is a separate API. Individual institution will decide whether to use it.
Ray: yes. Reconciliation between official enrollment and site membership is a lot of work. We need to make a clear boundary, where the data is from, is it imported, from cm services, or from sakai?
Glenn: don't think of writable api, readable api, people would need web services.

Forms can be done by course site admin tool. This tool can read/write(write overrides EIS data, local institution decides)

What are the connections between enterprise roles and lms roles? Needs to have a mapping in CM.

Daisy: Everyone has an eid?
Josh: Yes, everyone has eid. We need to make one up if there is none.

Glenn: How would exiting things need to be changed?
Josh: at least 4 things:
1. site info
2: Section info
3: Gb
4: Roster

All 4 above might want to display status, roles, CM specific data. CM data will enhance these 4 tools. For example, currently LdapID is the only way to uniquely identify a person in sakai. Gradebook wants to show a student id that's meaningful to the instructor. Roster also might want to display a student id . (this is documented in SAK-2924.)

Duffy: how do we know if a CoureSet contains dept, or course.
Ray: it's institution specific.
Duffy: eid, not every school has it. It has id semantics. Id needs another semantic field, that specifies what type of id it is .

Glenn: LmsMappingService stores maps, how is it being used?
Josh: CmGroupProvider uses it. It talks to CM and LmsMappingService.
CmGroupProvider calls LmsMappingService's methods. Sites and Groups are created by CM data.

Group provider needs UserProvider. Cm users are from enterprise, so are UserProvider's users. User directory is a superset of CMS users.

2 examples of site creation:

1. top level site at dept level,
second level site at course level, have one admin manage all courses
2. 101, 101-fall 05, 101-winter06 (canonical hierarchy)

Sites and Groups both need to be hierarchical.

Josh: (for now) wants a simple LmsMappingService which returns enrollment set. For example, gradebook can query and ask who are enrolled, enrolment options. (one usage might be: in gradebook show the official enrollment status in the exported CSV. This has no UI changes, might be a doable deliverable for CM project in 2.2)

Josh: GroupProvider needs an id, it can be group authz id, generated by unpacked() ???, they are enterprise defined groups....If no provider id, then bypass it... (I did't catch all of these - lydia)
UserProvider calls UserServices to get more info, based on ref id. (Siteid/groupid/.. )

GroupProvider is used to cache the enterprise data, thus avoid having authz calling out all the time. It's used for doing authz, for displaying tabs.

SVN location
Glenn: SVN top level modules are organized based on:
Function cohesion(the ability for people to choose or not to choose.) Eclipse dependency, maven artifacts.

CM code will follow the new SVN structure. With the new SVN structure, it can be decided right before 2.2 whether we want to include it in the release or not, just by changing the external reference inside top level /sakai module. It will be included if we have a client by then, such as gradebook (or maybe if other schools want it.)