I will try to upload my working directory later today.... read more
I am currently working on the new implementation.
It makes use of the gSOAP and the UAPI.wsdl file that is installed with the Windows utility. Simply put, this file is a large XML(SOAP wsdl) file that gives the layout of all functions and interactions within the utility.
Following the gSOAP model and the existing utility's layout, I plan to have separate "server" and "client" sides. The way this would work is to have the client end be the cli or gui makes SOAP(XML) requests to the listening server. In order to fulfill the request, the server makes the appropriate UDP requests to the physical switch. The switch's response then flows back through the server side to the client.
Although this approach would be quite modular, I would like to keep the project as simple as possible for others to understand and use. As I go, I will continuously look for ways to merge the client and server side roles.... read more
After a recent discovery of gSOAP and the UAPI.wsdl file, which is installed with the Netgear Windows utility, I have paused development of the current implementation. At the moment, I am weighing out the benefits of using gSOAP as opposed to following the current design without gSOAP.
Needless to say, this implementation dilemma will be resolved soon.
Feel free to give input.
I'm very close to releasing a functional program.
Just to get a feel for my coding style, the current organizational model has led me to use six source files and six header files. The only global variable in use is an int called verbosity which determines how much feedback functions should supply. Also, each source file has a header file that contains a detailed interface specification.
It has been designed in a way that will allow for seamless integration with code for an interactive cli, concurrent multi-switch communication, and even multi-threading.