Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: MNET 1.0 workplan.

Obsolete:MNET 1.0 workplan

From MoodleDocs
Revision as of 12:14, 18 March 2007 by Helen Foster (talk | contribs) (category edit)

Work involved

Infrastructure

  • RPC layer
    • Pick a library
    • Make sure HTTPS support is solid, including handling invalid certs
    • Make sure HTTPS-related errors are reported in a useful fashion
    • Add msg encryption and signing (at what layer?)
  • Revamp Auth into multi-auth
    • We will be writing a auth/mnet plugin
  • Review/revamp SSO plugins infrastructure
    • We will be writing sso/mnet
    • Deal with logout
    • Config UI
  • Fix pending bugs in multi-enrol
    • We will be writing enrol/mnet plugin

Base protocol

Protocol should only implement the trust negotiation and setup, and a allow moodle-style introspection, so that a moodle install can probe "what do you offer?".

From there, everything else are 'extensions'. We will have to define an API for modules/plugins to make outgoing calls and to register calls. (yuck)

The "Hub"

While the protocol itself is P2P akin to TCP/IP, it still benefits from a central directory to find other nodes. Our P2P protocol doesn't have the need to avoid central directories like file-trading protocols do ;-)

So we should write a Moodle Module to be run on a central site (one for enetwork.nz, perhaps for moodle.org too) in the 'sitecourse' to run a simple self-registering scheme.

Older notes

Trust and encryption

  • HTTP client to handle HTTPS correctly, and dealing with self-signed certs in a user-friendly way
  • Define a simple API to
    • Publish pub cert
    • Publish services offered
    • Trigger services offered
    • Create "allow users to SSO" service
      • Options: users shortlist, remote admin approval
      • Requires Auth API work and plugin changes
    • Create "allow users to enrol in courses" service
      • Options: courses shortlist, remote admin approval
      • Requires Enrol API work and plugin changes

User-friendly admin pages

  • Establish and manage trust relations
  • Open/close services
  • Each service with an associated usage report. Examples:
    • What remote users are logging in, from where, which remote admin OKd them
    • What remote users are enrolled in, from where, which remote admin OKd them

Protocol and services

  • TODO

Core Moodle changes

We will need to

  • Review enrolment plugins API -- perhaps bring in some minor changes
  • Rework auth plugins API as discussed in the Multi Authentication plan