diff options
author | Fatih Degirmenci <fatih.degirmenci@ericsson.com> | 2015-11-29 21:45:16 +0100 |
---|---|---|
committer | Fatih Degirmenci <fatih.degirmenci@ericsson.com> | 2015-11-29 21:45:16 +0100 |
commit | 7b1fa9630daaec766fc4a7c721550cf31499472a (patch) | |
tree | a27fed24edb09f1af6853d31adfc4dbcf07d77a6 /docs/state-of-code.rst | |
parent | c0c1a3e9be0c8c7bdd73700fc34873720bfd81aa (diff) |
Example documentation for LSOAPI
Change-Id: I58bd3aa451be6e50d764b2db519d234739d628a4
Signed-off-by: Fatih Degirmenci <fatih.degirmenci@ericsson.com>
Diffstat (limited to 'docs/state-of-code.rst')
-rw-r--r-- | docs/state-of-code.rst | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/docs/state-of-code.rst b/docs/state-of-code.rst new file mode 100644 index 0000000..2978c48 --- /dev/null +++ b/docs/state-of-code.rst @@ -0,0 +1,28 @@ +============ +Introduction +============ + +This is a proof of concept prototype implementation enabling the creation and management of MEF EPL Services. + +Being a proof of concept prototype, there are some areas which have received only superficial coverage or no coverage at all. Following are items that should be addressed when evolving this to a production oriented implementation + +1. The current test suite is reasonable, but exhaustive. Production targeted version should have more thourough test coverage +2. Exception handling is only superficially implemented. A production system should include a more robust exception handling and error reporting architecture +3. Only a subset of the MEF Attributes have been implemented. Long term the goal is to evolve this code base to fully support all MEF paramaters +4. We are only implementing a portion of the data model for the sake of expediency. + - Only EPL service is supported at the moment + - Currently, the service repo is hard coded to hold EPL (we have not implemented the more general MEFSvc and Eline/ELine/Tree classes that in the future will also reside in the repo). + - The MEF service hierarchy (MEFSvc->Eline->EPL) need to be architected and implemented + - The SvcMgr needs to be architected in order to handle multiple service types from a REST API perspective and from a persitance perspective + - the REST URL/path architecture is currently hard coded, should be configurable at some point (config file, etc). +5. There has not been a definitive analysis of which specific service attributes are recieved, generated, or queried at each service layer. + - It would be very useful to do this analysis, and then reflect in the code through structure and documentation, which attributes are set/queried at each layer + +============== +Specific To Do +============== +1. Who supplies/generates evcMaxSvcFrameSize? Currently hard coded to 1600 in EplService.create() +2. Make sure for all XXXClient.create(xxx), that we capture the returned version, in case the service layer modified it + - for example epl = eplClient.create(epl) +3. Check for nulls when prior to printing out lists in dump() fxns +4. Unique EVC IDs are being generated via an internal counter. This of course does not scale nor survive restart. A proper unique ID generation approach will be needed for production. |