Changes between Version 3 and Version 4 of GEC12GeniAmAPI


Ignore:
Timestamp:
11/03/11 17:28:14 (8 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC12GeniAmAPI

    v3 v4  
    3232 * We agreed to two change sets, completing the list of changes to include in AM API version 2. We will:
    3333 * Adopt change set A for inclusion in AM API version 2: RSpecs are GENI schema XML
    34  * Adopt change set B for inclusion in AM API version 2:
     34 * Adopt change set B part 1 for inclusion in AM API version 2:
    3535  * All methods include a new 'options' XMLRPC struct argument with no required values, supporting aggregate innovation
     36 * We expect to also include set B part 2 in API version 2, assuming we can quickly address a few outstanding questions:
    3637  * All methods return an XMLRPC struct consisting of (1) a return 'code', (2) the return 'value' from API v1, and (3) a human readable 'output' on errors, plus optional aggregate specific entries
    37  * Discuss details on some parts of change set B
     38 * We will continue to discuss details on some parts of change set B part 2, to finalize AM API version 2:
    3839  * This discussion to continue at the coding sprint
    3940  * Error codes: integers? or strings? (including a specific namespace rather than the more discrete and arbitrary integers)
     
    4849=== Selected Discussion Points ===
    4950 * Change set A (RSpecs are XML) was adopted without discussion
    50  * Change set B (new options argument and new return structure) was adopted with minor discussion.
     51 * Change set B part 1 (new options argument) was adopted with minor discussion.
     52 * Change set B part 2 (methods return XMLRPC structs) has a few minor open questions, and should be in API version 2 if we can resolve these issues shortly:
    5153  * We must agree to and document GENI error codes
    5254  * Error codes were proposed as integers, with the space divided by aggregate developer. That either wastes codes or limits or both, while also hiding in a translation table whose codes these are. Why not use strings?