Date
28 May 2014
Attendees
John Clyne, scott, alan
Agenda
- Review WASP API
- Discuss public/developer APIs and documentation structuring
- Next steps toward working prototype
Notes
We reviewed and approved the WASP API
With the most recent commits to the 3.0 branch the number of documented class methods has grown quite large. One of the aims of refactoring effort is to facilitate extensibility by both 3rd parties and the NCAR development team. However, it is becoming difficult to identify both which classes and which class methods are needed by potential developers. Possible ways to improve this situation include:
- Defining a new C++ namespace and adding "public" classes, such as ControlExecutive, RenderParams, and VDC to that name space. This would help cull out the internal "helper" class objects, but would not address the problems of having a large number of public methods available on a class. Dozens of public methods exist for any subclass of the Params class, for example.
- Explore options in Doxygen for grouping or tagging public and non-public classes and methods.
- Produce separate documentation that identifies "useful" classes/methods
- Some combination of the above.
We also discussed the need for producing a spreadsheet to track class objects that have "passed review". Once a class has passed we hopefully need to longer continue to review it.
Alan is very close to having a prototype that is ready for review. We discussed the need to address some of the above to help the review process.
Action Items
| Description | Who |
|---|---|
| Experiment with C++ namepace options to see how we might use them to help identify public classes/methods | Alan |
| Research options in Doxygen to improve identification of public class/methods | John |
| Create spread sheet to check-off completed (reviewed) classess | John |