Obsolete:MNET 1.0 workplan: Difference between revisions
From MoodleDocs
No edit summary |
Helen Foster (talk | contribs) m (categories, formatting) |
||
| Line 1: | Line 1: | ||
= Work involved = | == Work involved == | ||
== Infrastructure == | === Infrastructure === | ||
* RPC layer | * RPC layer | ||
| Line 17: | Line 17: | ||
** We will be writing enrol/mnet plugin | ** We will be writing enrol/mnet plugin | ||
== Base protocol == | === 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?". | 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?". | ||
| Line 23: | Line 23: | ||
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) | 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" == | === 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 ;-) | 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 ;-) | ||
| Line 29: | Line 29: | ||
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. | 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 = | == Older notes == | ||
== Trust and encryption == | === Trust and encryption === | ||
* HTTP client to handle HTTPS correctly, and dealing with self-signed certs in a user-friendly way | * HTTP client to handle HTTPS correctly, and dealing with self-signed certs in a user-friendly way | ||
* Define a simple API to | * Define a simple API to | ||
| Line 44: | Line 44: | ||
*** Requires Enrol API work and plugin changes | *** Requires Enrol API work and plugin changes | ||
== User-friendly admin pages== | === User-friendly admin pages=== | ||
* Establish and manage trust relations | * Establish and manage trust relations | ||
| Line 52: | Line 52: | ||
** What remote users are enrolled in, from where, which remote admin OKd them | ** What remote users are enrolled in, from where, which remote admin OKd them | ||
== Protocol and services == | === Protocol and services === | ||
* TODO | * TODO | ||
== Core Moodle | === Core Moodle changes === | ||
We will need to | We will need to | ||
* Review enrolment plugins API -- perhaps bring in some minor changes | * Review enrolment plugins API -- perhaps bring in some minor changes | ||
* Rework auth plugins API as discussed in the [[ | * Rework auth plugins API as discussed in the [[Multi Authentication]] plan | ||
[[Category:Developer]] | |||
[[Category:Community hub]] | |||
Revision as of 07:32, 4 September 2006
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
