Proposals/MNet replacement/Connection manager
From Mahara Wiki
< Proposals | MNet replacement
Web Services Client Connection Manager
Summary
What this spec is about
Target Release
Owner
References
references to any other documentation
Motivation
Why we want this feature
Use Cases(Stories)
Story 1
Description
Preconditions
Steps
Postconditions
As a plugin developer, I want to be able to have a logical reference to a list of connections that refer to 1 or more web service end points that I can pass attributes to for web service call execution.
As a Mahara administrator I want an interface that enables me to configure a logical reference to a a list of web service connections.
These web service connections must adequately describe the supported protocols of SOAP, XML-RPC, and REST using the payload encodings of SOAP, XML, URL, and JSON where appropriate. The connections must also support the configuration of authentication options of token, user+password, OAuth1.x and WSSE where appropriate.
Specification
Description
What the changes are that are required
Assumptions
Issues
Process Flow
UX
This should contain discussion of the UX implications of the change. If the UX discussion already has a design proposal, a link should be inserted here. If the discussion is ongoing it can take place in the whiteboard area.
Wireframes, Mocks, Videos and UI Markup
Links to any visual assets that describe the changes.
Discussion of use cases and actors is encouraged where applicable.
Classes, Utilities
Database Tables
Security
Modifications to Other code
Testing
Brief instruction for reviewers to exercise the changes, including expected results where non-obvious.
Dependencies
Is this functionality already supported in other services? List the appropriate API calls and if they are extensions or base API functionality.
This should describe any cross project dependencies. This should include:
* changes to Mahara services * changes in external projects
Links to particular patches should be included in the whiteboard area.
Doc Impact
This should describe any changes to Mahara documentation that will be required. This could include:
* settings file changes that will be required * changes to default behaviours * any deprecation or obsolescence notices
Milestones
How the work can be broken up