From StringLE to DockLE… Erm… Maybe…

Getting on for a decade ago, I doodled an approach for creating user a user defined personal learning environment based around online applications and resources: StringLe, the string’n’glue learning environment (more and more and more).

StringLe was of the web. A StringLE environment configuration comprised three things:

• the username and tag for a particular delicious social bookmark feed that contained a list of web applications that were linked from the top menu bar of a StringLE set up; tools included things like online office tools, drawing packages, and audio and image editors
• a link to an OPML feed: this feed populated a Grazr widget in the left hand sidebar that could be used to load in further RSS feeds to act as more comprehensive nested menu options that could be used to pull resources into the environment.
• a homepage URL for the environment.

The idea was simple – through managing various RSS feeds, the user could create a workspace configured to load in a variety of tools (web applications) arranged along a top tabbed menu bar and online content pages accessed via an OPML navigation widget and inpage RSS viewer widget (actually, the OPML and RSS viewer widgets were one and the same: Grazr? Remember Grazr? I went through phase of packageing MIT courses as OPML files for rendering in Grazr eg here and here), as well as using the environment as a normal web browser, and bookmarking links visited within the space into one of the feeds exposed via the navigational OPML feed.

It was a throwaway toy, but one that demonstrated a way of pulling a range of separate applications together that might be used within a particular course or course activity. For different courses or activities, it was easy enough to pull together different collections of tools for that particular purpose.

This notion of online tool collections – workbenches, perhaps? or tool suites? – is used, in part, in things like SagemathCloud, or the IBM Data Workbench, where a user is provided access to a range of different online applications within a single online environment.

Those workbenches go much further, however, and provide an online workspace in the form of a user filestore that can be accessed by all the applications within the suite. Services like Sandstorm also resemble StringLE in the sense that they provide an environment from within which a user can launch a range of user selected online applications.

For anyone whose followed this blog for any period of time, you’ll probably know the same ideas just keep getting revisited and recycled. So now, for example, it strikes me that a Docker Compose file provides another way of defining a user configured workbench comprising multiple linked applications, along with a workspace in the sense of a shared file area that can be used to pass files between the applications.

So for example, here’s an example from earlier this year of the Docker Compose script I used to pull together a set of containers to re-implement the TM351 monolithic VM as a set of linked containers (raw dockerfiles on Github).

What might me quite nice would be to add a Flask container to the mix to set up a simple webserver, and generate a simple HTML file from the dockerfile to act as a floating menu panel that has a set of buttons, one for each application, that would let me click through to that application. A simple wrapper script would then: take the docker-compose file, add a flask control panel container to it, create the menu HTML from the docker-compose file, run docker-compose over the docker-compose file to launch the containers, pop the HTML menu up in a browser window.

Anyway… suffice to say that the app collection idea reminded me of StringLE, but  reimplemented via a Docker Compose script – as a DockLE?! – and using applications running in linked containers, rather than more loosely connected web apps identified via RSS and OPML feeds.