Notes for discussion on 2013-08-07 surrounding refactoring of OpenVisualizer and addition of a remote UI.

Code Review

See OpenVisualizerApp directory.

App – Using ArgumentParser replacement for OptionParser. Notice the license at the top of the file, which seems like standard practice. Also, removed logging NullHandler since we have conf file.

CLI – Use cmd module.

See SConstruct for developer use. Not needed by end user if we have an installer (see below). Runs sphinx, GUI, and CLI. Manages options and Python paths. Creates 'build' directory for log and conf files.

Packaging/Installation

I agree that we should create an easily installable package. (using pip?) We need this anyway to make OpenWSN easier to try out.

See OpenVisualizer page for current prerequisites. For web UI, probably bottle and ws4py.  Also need SCons for developer use.

Simulator Integration

I don't know what is needed here. However, it is possible now to run openVisualizerCli with the --sim option.

Documentation

Sphinx is very widely used for Python, Doxygen rarely. Use the idioms of the language. Also see Read the Docs site – beautifully rendered, Sphinx-based doc hosting for open source projects.

Messaging

WebSocket

The WebSocket (RFC 6455) protocol provides two-way, message-based communications over a single TCP socket. This capability describes our basic requirement for remote communication. It is designed for a web application, but also may be used independently. As a standard, it supports OpenWSN's standards-based approach. Due to its close relationship to HTTP and web communications, we expect it to become widely adopted. It already is supported in the well known browsers. There are implementations for Python, as described on the Remote UI page. In addition, libwebsockets provides a lightweight implementation in C.

Alternative Messaging Approaches

We researched the projects below, but they are not our first choice. We may investigate further at a later date.

Nanomsg and ZeroMQ provides a common messaging API for a variety of endpoints – threads, processes, and machines. They are open source, but not standards. However, it would be efficient to use a single tool for messaging across all domains.

Nanomsg is developed by Martin Sústrik, the original author of ZeroMQ. Sústrik left ZeroMQ due to a dispute over trademarks, as described in a Linux Weekly News article.

Celery provides a distributed message queue, but is more heavy-duty and requires a message broker.

Messaging Between Processes

As future work for the embedded LBR, we plan to use the native POSIX message queue for inter-process messaging, due to its built-in availability. The posix_ipc module for Python provides access to this functionality.

Web Implementation

See Web Framework section of Remote UI page. As projects, Bottle, web.py, and CherryPy all are reasonable solutions. I favor Bottle for the maintainer's project management, active development, excellent documentation, and built-in JSON support. Both web.py and CherryPy are suffering from some development paralysis now – mostly because it seems the maintainers are preoccupied with other projects.

ws4py provides a WebSocket server.

Both Bottle and ws4py should work with the Python standard library's wsgiref server. I think this is 'good enough' for our use. If necessary, bottle supports use of the CherryPy web server (which web.py uses by default). ws4py also supports CherryPy, but may bring in more of the framework. In addition, both bottle and ws4py support gevent.

GUI vs. Web

See discussion on Remote UI page, especially under UI Implementations heading. I think the Web UI is most valuable, but a GUI is valuable for a user that does not want the LBR to maintain the UI. Given that we have a local GUI and must support the Web UI, I think the effort to support a remote GUI is incremental. At the same time, we don't want to get bogged down with a feature that won't be used much.

Also, I don't see much value for a remote CLI when SSH is available.