First Commit

3 files changed, 77 insertions, 0 deletions

diff --git a/doc/dev-notes.md b/doc/dev-notes.md
new file mode 100644
index 0000000..1ff24b6
--- /dev/null
+++ b/doc/dev-notes.md
@@ -0,0 +1,9 @@
+## REST Clients Notes : CoSClient, EvcClient, EplClient
+1. Provide rest communications to cosmgr, evcmgr, and eplmgr repsectivly.
+    - provide create/request/update/delete capabilities
+    - these services must be running within tomcat
+    - each has it's own separate war file
+2. Creating resources
+    - The create() methods take cos/epl/evc objects as inputs 
+    - Not all inputs are known at time of resource creation, and the create service itself will set some of the parameters, and the all return object of the type that was created which will capture any values set within the create service (in addition to remembering the values originally supplied)
+    - You must capture the object returned by the create function, as there will be values that were set during that proccess 
diff --git a/doc/sample-json.txt b/doc/sample-json.txt
new file mode 100644
index 0000000..d46dc4c
--- /dev/null
+++ b/doc/sample-json.txt
@@ -0,0 +1,46 @@
+
+// cos
+Content-Type	application/json
+Accept			application/json
+{
+	"id" : "gold",
+    "commitedInfoRate" : 100,
+    "availbility" : 99.9,
+    "frameDelay" : 2.5,
+    "jitter" : 3.6,
+    "frameLoss" : 4.7 
+}
+
+// evc
+Content-Type	application/json
+Accept			application/json
+{
+  "broadcastFrameDelivery": "UNCONDITIONAL",
+  "ceVLanIdPreservation": true,
+  "ceVlanCosPreservation": true,
+  "cosId": "gold",
+  "evcMaxSvcFrameSize": 1600,
+  "evcType": "POINT_TO_POINT",
+  "id": "11:00:11:11:11:11|11:00:22:22:22:22",
+  "maxUnis": 2,
+  "multicastFrameDelivery": "UNCONDITIONAL",
+  "oneWayAvailability": 0.99,
+  "oneWayFrameDelay": 17.43,
+  "oneWayFrameLossRatio": 0.01,
+  "uniIdList": [
+    "UNI-1",
+    "UNI-2"
+  ],
+  "uniIpList": [
+    "192.168.1.1",
+    "192.168.1.2"
+  ],
+  "uniMacList": [
+    "11:00:11:11:11:11",
+    "11:00:22:22:22:22"
+  ],
+  "unicastFrameDelivery": "UNCONDITIONAL"
+}
+
+// for the simple ping test gets
+Accept			text/plain
\ No newline at end of file
diff --git a/doc/state-of-code.md b/doc/state-of-code.md
new file mode 100644
index 0000000..0a9eff3
--- /dev/null
+++ b/doc/state-of-code.md
@@ -0,0 +1,22 @@
+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.
\ No newline at end of file