...
| Description | Details | Decisions |
---|
1 | Assume flat attributes (no complex data types) but data could be stored as json object in SPI impl. for convenience/PoC |
|
|
2 | SPI Implementation NOT using Model (service) current ENM SPI does! |
|
|
3 | Are we going to have XPath/query builder? | - We should decide based on what the users want to use/is easy to use
- We don't want a query builder that eventually mimics XPaths functionality, use what is defined already XPATH as a based but maybe supplement with a xpath-builder
|
|
4 | When do we get attributes? | How do control how many attributes we get back? | We will have an (optional) output specification with the following options - Default is no attributes
- All Attributes
- Specify attributes - output specification (filter)
|
5 | Should we use the name node or fragment? |
| We decided on the name DataNode |
6 | Do we want to split the interface? | Maybe we could just have a 3 Alternatives - all in one interface
- Limited number of interfaces e.g Data Objects/ Data Persistence/Query
- Very fine grained (see below)
| - DataStore SPI - methods to add data.
e.g dataStore.addChild(parentDataObject, childDataObject) - CpsAdmin Interface will handle the dataspaces and anchors
- Module SPI - responsible for handling modules and module sets
The above will be in separate maven modules. Any data object they need will be in the same module. We will not have a querybuilder in SPI but the SPI will have to understand the cpsPath. The java API will use a builder pattern to create a cpsPath |
7 | Do we need objects for very simple concept like dataspaceName which are just a string? |
| - We will not use objects for name fields. We will just use Strings.
- We may need an object for AnchorName
|
8 | Should we share common objects between the Java API and SPI? | Alternatives - API depends on model objects defined in SPI
- SPI depends on model objects defined in API
- Extract common model API in separate module (deliverable)
- Use separate models with slightly different names e.g Anchor in API and AnchorDetails in SPI (CPService will transfer when needed)
|
|
ENM SPI Study
Details about the ENM SPI can be found here: ENM Study
Interface Proposal
can be found at : Interface Proposal for CPS
Proposed Future Implementation of CPS SPI
...
| Name
| Capabilities |
---|
1 | ModuleStoreService | - Collection<String> getModules(String dataspaceName, String moduleSetName);
- Collection<ModuleRef> getModuleRefs(String dataspaceName, String moduleSetName);
- Void deleteModuleSet(String dataspaceName, String moduleSetName);
|
2 | ModulePersistenceService
| YangModule getModule(moduleRef)Collection<YangModule> getModules(moduleSetName)
|
3 | YangModule | ModuleRef getModuleRef(moduleRef)String getModuleContent(moduleRef)
|
4 | ModuleRef | String getNamespace(moduleRef)String getRevision(moduleRef)
|
5 | ModuleSet | - String getName(moduleRef)
- Collection<ModuleRef> getModuleRefs()
|
Javadoc