BOLD = PLEASE READ

Start: 9:30

• Working with Phil on primarily the controller class so far.
• Phil had to step out so I am working on the DataDictionary
• Changed all the isRemotes to isLocal to keep with the theme of the other classes
• Added a addItem method which takes in DataElements.  Now you can either add a new entry with all parameters or add a DataElement.
• Made the old getItem private.  This method is used internally but from what I can tell, publish or subscribe will take its place in external use.
• Took the DataElement variables out of the struct.  This was obsolete code, the newer serialize method only takes the name and data, so the struct wasn’t really required anymore.
• Added publish and subscribe methods.  I am not sure if I understand the purpose correctly, but I think it is to get the pointer to the entry no matter if it already exists or not.  I was also confused by why we would want two methods that do the same thing, but I guess the owner will publish, and the other classes, that want the data, will subscribe.
• Moved sendRemoteData to private.
• Committed changes to the 4 files involved with the DataDictionary/Element classes.
• More changes to the Controller class were made, Phil wants me to make a test program for controller and related classes.
• Cleaned up all compiler errors.
• Added TempControllerTest(executive), TempSrgt(Top-level controller), TempLt(Mid-level controller), and TempPrivate(Low-level controller) classes to the project, to test everything related to the controller.  Once a local test works, I will have to ask Phil how to best handle remote data.
• Parent class methods which are virtual, can be called using __super::nameOfMethod.
• Eventually figured out why it kept telling me the child classes of controller were being considered abstract.  Apparently setting a method to equal zero makes it abstract.  This was actually in the wiki (= 0) but I thought it was an emoticon someone stuck in there…
• I didn’t get much done because it took me so long to figure that out, but now that is done it shouldn’t take long to finish the local tests.
• I will need to finish the classes for the test tomorrow and then update the arduino classes to test remote data.  Setting up the remote data test may also require changine the way stuff is sent over the wire.  How it is currently done is described below.

• EXPLANATION OF HOW THINGS GO ACROSS THE WIRE CURRENTLY:  The way I have it set up, the entries are iterated through and the remote objects are added to a buffer.  This buffer  is then sent across the wire and the import method places everything in the correct place on the other side.  The way its currently set up, only name and data are transferred.  It is assumed the name, size of data, and isLocal will never change after initialization of the DataElement and will be uniform on both sides.  This process is handled by the sendRemoteData() method, which was designed to be run only by the executive at the end of a cycle.  Any suggestions on how to do this better are greatly appreciated.

End: 5:30