Historical overview

How did the design and development of the OOCSI system start? How did we proceeed to build all these features? And how to keep on doing this for almost decade?

The beginning

In 2013, we started with a test development of the core technology: a client-server implementation in Java. The communication was based on TCP sockets and followed the Sun reference implementation of Java-socket based bi-directional communication. We implemented a simple human-readable protocol (see Table 1) and channel multiplexing that would allow for bi-directional sending and receiving of messages of one or more named channels (or the individual client handle). Being human-readable, the protocol could be used even from a Telnet console and allowed some students to implement their own clients (see below). The protocol allowed for sending of messages, subscription handling to channels and simple handshakes for session start and end. All communication was textual with UTF-8 encoding and messages allowed for arbitrary number of components, as key-value pairs. We used Java serialization and deserialization mechanisms to send dynamically structured messages over the sockets.

As a next step, we packaged the client library as a Processing library which allowed for easy deployment in students’ Processing installations. Together with the library code we packaged a collection of simple examples showing how to use the library in different communication scenarios. This library is to date the most comprehensive collection of examples that grew over time when we implemented more features in the middleware. When using the middleware in education, we still relied on (1) a locally started server for the entire class and (2) individually zip archives of the library to be unarchived and moved into the Processing library folder on student computers. Soon, we moved to a central in-house server that would host the server and a more extensive official Processing library that could be installed from the Processing library manager with a few clicks. From this stage, we observed a growing momentum in use of the middleware in our local community.

Extending the client ecosystem

The first non-Java platform implementation was contributed by a student, who ported the protocol and data serialization mechanisms to C++, so the middleware could be used with Espressif ESP8266 and ESP32 boards. This library was adopted by the core team in development and we improved it over the next years in robustness, keep-alive mechanisms and serialization. In 2015, we had implemented different serialization protocols, which the server would automatically switch to depending on the client platform and initial handshake. This allowed fluent communication between clients on various platforms, whose messages would be deserialized on the server and then specifically serialized again for the recipients on potentially other platforms.

Due to growing needs to support WebSocket and HTML-based digital prototypes, we wrapped the original Java server in a web stack based on the Play Framework (in 2015) which allowed for WebSocket clients and showing server metrics, documentation and, later on, various small tools for bootstrapping middleware projects, automation and debugging (in 2019). Next to built-in bridges to OSC (already in 2013) and MQTT (in 2016), and a cross-compiled C# client in 2014, we developed a client implementation in Python in 2017 and then in Node.js in 2019.

Investing in the core

In parallel to the client developments, the core platform evolved as well. Experiences from the community led to improved robustness, extensions of what data could be sent, new tools for prototyping (from 2018), presence detection and channel operations (from 2018), and further opening the system with a central logging channel that allowed for visualizing the graph of connected clients and their data flows (from 2015). This led to a series of visual data canvases which we were popular education tools as they visually explained connectivity and communication to students.

Documentation of the middleware was initially provided through examples, in lectures and tutorials. Once we moved to GitHub for version control, we started using the built-in pages and the wiki system to provide more information on how to start with the middleware. This is complemented by information from the landing page of the server component. To increase visibility within our own community, we used the wiki hosted by the university to further direct attention. Finally, we published the software bundle as a dataset publication. In 2022, all documentation was consolidated on this website.

Future roadmap

The OOCSI story is not done, not at all. Just this year we built the heyOOCSI extension that allows to annotate clients with meta-data that can be used in a data canvas or even HomeAssistant. We are still working on this website to extend the documentation and provide more examples on how to work with OOCSI in design.