Component Specifications
From SLIS Second Life Wiki
A component specification is a document which details the 'back-end' of a specific part of Sloodle. Note that this does not necessarily dictate the in-world appearance of the object, so in-world developers are free to implement and represent the specification in whatever way they see fit. However, the specification does dictate a mandatory method of communication, and the general idea of what the component is supposed to do with the communicated data. In theory, it should be detailed and precise enough that one person can work on the Linker Scripts in the Moodle module, and another can work completely independently on the in-world objects, and their work should be completely compatible. (In practice though, it is always advisable to collaborate!)
Contents |
[edit] Specifications List
The following lists all current component specifications. If you write a new one, please add it here:
[edit] Guidelines
It is impossible to give an exhuastive list of guidelines to follow. In many cases, it is useful to copy the structure of an existing specification.
[edit] Specifics
[edit] Communication Format
Your specification should always follow the established communications format for Sloodle. Whatever form of communication is used, be sure to specify the following:
- Status codes - what status codes are specifically expected? (You don't normally need to mention the standard error codes)
- Side effects - are there any side effect codes to know about?
- Data lines - how many lines? What is on each line? Remember to mention all possibilities
[edit] HTTP Request
- URL - what URL should be requested?
- Standard parameters - what standard parameters are needed? (e.g. password, avatar name, etc.)
- Custom parameters - name and purpose of custom parameters
- Method - what method (eg. GET or POST) is expected? (You can usually ignore this unless you need a specific method)
[edit] XMLRPC
- Data channel key - how is it communicated into Moodle?
- Data channel availibility - when is it expected to be open?
- Data response - what response is expected? (Note: some kind of response must be made from SL)
[edit] Email
- Address - how is the email address communicated into Moodle?
- Response - what response expected? (Note: response is optional)
[edit] Link Messages
- Channel - what channels are to be used for what purposes? (Note: this is the integer parameter of a link message)
- String - what format is the data string expected to use?
- Key - is a key expected? What for?
[edit] Chat Messages
- Channel - what channels are to be used for what purposes? (Note: this is the integer parameter of a link message)
- String - what format is the data string expected to use?
[edit] General
It is advisable to follow these guidelines when writing a specification:
- Conventions - make sure you follow the Sloodle coding conventions
- Consistency - try to follow a similar structure to the other specifications
- Structure - split your specification into sections, with clear and concise headings
- Clarity - avoid ambiguous or confusing language
| This page is part of the Sloodle documentation | |||
|---|---|---|---|
| SloodleDocs Home | User Documentation | Administrator Documentation | Developer Documentation | Sloodle Wiki Home | |||
