1 #########################
2 <Feature> Developer Guide
3 #########################
8 Provide an overview of the feature, what it logical functionality it
9 provides and why you might use it as a developer. To be clear the target
10 audience for this guide is a developer who will be *using* the feature
11 to build something separate, but *not* somebody who will be developing
12 code for this feature itself.
14 .. note:: More so than with user guides, the guide may cover more than
15 one feature. If that is the case, be sure to list all of the
18 <Feature> Architecture
19 ======================
21 Provide information about feature components and how they work together.
22 Also include information about how the feature integrates with
23 OpenDaylight. An architecture diagram could help. This may be the same
24 as the diagram used in the user guide, but it should likely be less
25 abstract and provide more information that would be applicable to a
28 Key APIs and Interfaces
29 =======================
31 Document the key things a user would want to use. For some features,
32 there will only be one logical grouping of APIs. For others there may be
33 more than one grouping.
35 Assuming the API is MD-SAL- and YANG-based, the APIs will be available
36 both via RESTCONF and via Java APIs. Giving a few examples using each is
42 Provide a description of what the API does and some examples of how to
48 Provide a description of what the API does and some examples of how to
51 API Reference Documentation
52 ===========================
54 Provide links to JavaDoc, REST API documentation, etc.