Private:sharangi

From NMSL
Revision as of 00:19, 5 July 2010 by Ssa121 (talk | contribs)

Summary of accomplishments by Somsubhra Sharangi.

5 June 2010

  • Added a socket listener for listening to the GUI events from PHP front-end.
  • Currently 7 events are parsed: Broadcast(start/stop), Programs(add/remove/update), Settings(load/change)
  • The events are forwared to config manager by the socket listener where the XML data is processed.
  • Moving to TinyXML from Xerces/XSD due to lightweight functionality and simpler APIs

TODO:

  • On the PHP side the XML messages are currently hard-coded. Need to change the GUI code to compose the XML messages from user input.
  • The events trigger changes which need to be rippled across the Mtv code. Need to interface with Kashik's call back code in the config-manager for this.

7 June 2010

  • INTERFACE INFO(Configuration Manager):
    • Interacts with Mtv class, GUI classes, Xerces lib and xsd code-synthesis lib.
      • Mtv: Calls load_config() method in ConfMgr class to load config params
      • GUI classes: call the load(), save(), saveas() and revert() methods of ConfMgr class to persist config information in XML files
      • Xerces lib: Not used directly. code synthesis uses it to create config_t classes from XSD file
      • Code Synthesis lib: creates wrapper classes based on config.xsd and populates with values from config.xml file. Uses Xerces lib to handle XML I/O. called by the ConfMgr constructor. helps implement file I/O in methods load(), save(), saveas() and revert() of ConfMgr class.
  • Checked in code for configuration manager and the related changes in Mtv class.
  • Updated the design document with the Configuration Manager section and added a new section for TestCases.
  • ISSUES:
    • Currently the environment/path setting is not automatic for the xerces and xsd libraries.
    • The Mtv code crashes when run in the Testbed machine. RESOLVED.

31 May 2010

  • Configuration Manager Code completed. Couple of things are left out for future implementation/integration with other modules. First is that, mutator APIs are not defined for individual config parameters. This is due to the assumption that the parameters will not be updated individually rather the whole configuration instance will be updated using the save()/saveas()/revert() APIs. In future if individual mutators are required they can be easily implemented bu updating the CongMgr class. Second feature that is not implemented is the individual-stream-per-layer SVC feature( i.e., vector of primaryTrains). This features is not currently implemented in rest of the code as well. Just the skeleton is created for future extendibility. We note that this does not hamper the single stream SVC handling features that are currently implemented.

UNIT TESTING:

  • By default the code compiles and runs by reading parameters from the config.xml file located at the local directory. No command line arguments or any other property files are required.

TODO:

  • Check how the GUI works with the current ConfMgr and if the load/save functions can be performed from the GUI.
  • Update documentation
  • Integration with the changes being done in other modules.

TODO Later:

  • Refactor code to a more object oriented design, e.g. Timeslicer.add_program(Program p) instead of Timeslicer.add_program(prog_name,prog_id,...). Currently not changing as it might break somewhere else. Just emulating old code behaviour after replacing the command line argument with ConfMgr.

24 May 2010

  • Configuration Manager: I propose the following changes in the current directory structure for configuration manager.
    • Class ConfMgr to have a constructor which takes a string as input param. The string will be the XML file name of the default parameter setting.
    • The class ConfMgr to have public get() and set() methods for each of the configuration parameters. As and when required, these methods will delegate the accessor or mutator functions to the property classes.
    • A new property class SystemConf to be added to handle the system parameters like NUM_ETH_THREADS. These parameters are currently defined as constant in the mtv.hpp and some other files.
  • XML schema: To simplify the process of adding a new configuration parameter we can use XML schema instead of simple XML. We define a structure for the config parameters using XML schema and then synthesize the classes directly from the xsd file using XMD data binding technique. I used the open source package CodeSynthesis to accomplish this. The distinct advantage of using this method are following.
    • We do not have to deal with the XML specific routines. The classes are constructed from the property names given in the XSD file. For example If we have a root-level element config in the XSD file we can create object of a class named config_t directly, without bothering to populate the class with values parsed from a XML DOM tree.
    • Each class also has the mutator and accessors generated which make it easier to manipulate the individual config parameters.
    • The root element is serializable. That makes it very easy to implement the load() and save() methods in the CongMgr class. Also it means the Conf interface is already implemented.
    • We do not need the NetworkConf, ProgramConf, TrainConf and the newly proposed SystemConf classes. these will now be automatically synthesized.
    • To add a new property we need to execute the following steps: (1) define the property data type in config.xsd, (2) add a value entry for the property in the "config.xml" file. (3) add the get() and set() methods for the property in the ConfMgr class.
  • TestCases: A proof of concept implementation was done to ensure that the features of XSD work as described. A small number of properties from the NetworkConf and SystemConf classe were used for testing the basic get()/set() method and the ConfManager load()/save() methods. Complete implementation and a more elaborate design/test document will be produced ofter the design is discussed in meeting.
  • TODO:
    • Discuss whether it is required to make the ConfMgr class a singleton.
    • Code re-organization: How is the sliding window implemented? (GoP level, Frame Level)
    • GUI access of the XML. PHP/XML API vs PHP/C++ api.

17 May 2010

  • INFO: XML to be used for the managing configuration parameters for MTV. It can be used also in generating ESG files or HTML code for the GUI later on. Xerces library from Apache group is selected for XML processing.
  • The current code needs the following header file changes to be able to compile with Ubuntu 9.10(2.6.31), gcc 4.4.1

timeslicer.hpp: <algorithm> mpe_pkt.hpp:<string.h> psisi.hpp: <stdio.h>, <stdlib.h> transmitter.hpp: change #elif to #else Svc_reader.hpp:<limits.h> esg_reader.hpp: <stdio.h>,<algorithm>,<cstring>,<limits.h> ts_pkt,hpp:<stdio.h>, <cstring>, <algorithm> FEC is not compiling after these changes.

  • libargtable2 is not available as part of standard distro. Considering bundling it with the source at a later point.
  • Created two new classes XMLUtil and TestConf for the generating the XML processing API and testing it. Some compilation problems with xml document synthesis.
  • Basic implementation with the elements of NetworkConf completed. Unit Testing underway.
  • Basic implementation of the ProgramConf class underway.
  • TODO:
    • Discuss design of a development environment with feedback from others on what softwares they are using and how to bundle it into a common dev environment.
    • Design point regarding initializing the XML processor module.
    • Integration testing with rest of the MTV code.
Retrieved from "https://nmsl.cs.sfu.ca/index.php?title=Private:sharangi&oldid=3561"
Powered by MediaWiki