The wrapper project
Thu Aug 21 11:06:54 CEST 2003
I'm back .... (been on holiday)
I've been thinking about stuff.
Once upon a time I was interested in "how to program" I think that
we now know how to do this (not perfectly, but adequately) - now I'm
interested in "fitting things togther".
I have convinced myself of the following:
1) Systems must be made of *isolated* components.
2) The components must communicate by asynchronous message passing
... (and a few more things which are not relevant to this discussion)
Isolation is the *essential* characteristic. It means that if one
component crashes, the other components must not themselves crash. Two
processes running on the same machine should be as isolated as if one
ran in (say) Sweden and the other in (say) the USA.
What these process are written in (language) and what they run on
(OS) is *irrelevant* - But the *protocol* between them is vital (hence
my thoughts on UBF and the like (see www.sics.se/~joe/ubf).
I would like to propose the construction of a series of "wrappers" -
What is a wrapper?
A wrapper takes an application that is NOT a isolated component, and
makes it into a component that IS an isolated component.
Here's an example. Take something that is pretty nasty to build (say
a media player like mplayer.
Mplayer is currently commanded by mouse and keyboard events.
I'd like to add a wrapper so I could control it from a socket, like
| +----------+ |
| | wrapper +------------------- socket -----
| +----+-----+ |
| | |
| +----------+ |
| | mplayer | |
| +----------+ |
On a unix system the *entire* app is started thus:
> startMediaPlayer Name PortNumber
Thereafter we define a simple socket protocol to command the thing.
(eventually UBF but not yet - for experimental purposes a simple
byte protocol will do. example:
byte 1 = 1 means start
3 play movie (file name in bytes 2..)
Completed applications should then be delivered as statically linked
binaries for a particular OS. Why (because it's very complicated to
get the right combination of shared libraries to get arbitrary
applications working properly).
Having defined the *protocols* the components can be implements and
distributed for different OSs.
I am currently pursuing this idea. My first component should be a
control wrapper round wxWindows so we can do GUI's - NOTE my view is
that the GUI is itself a *component* which is isolated from the
application which should be another component.
(Thus controlling mplayer needs two components and one control
process - The GUI component, the mplayer component, and a semantics
As proof of concept it would be nice is somebody felt the urge to
write a component according to this model.
Say an image display component.
This component would display an image (jpeg/gif) etc in an Xwindow
(or on windoze) manipulate the image.
NOTE the image component ONLY displays the image and has NO GUI - th
GUI must be done by the GUI component (which I am trying to write :-)
To start with I'd recommend the *simplest* possible protocols (Just
bytes) NO XML, No cobra, etc.
I will migrate to UBF when the appropriate encode/decode libraries
(If anybody cares to write a C++ UBF parser/deparser I'd be very grateful)
So do we have some volunteers -
PS - this could be fun. You can code in ANY language any OS, and do
your favorite app. All you have to do is make sure that you
application is *isolated* (no shared libraries) and is NOT controlled
by a GUI (most important) but IS controlled by commands from a socket.
It must also be started and stopped in a standardized was on each OS
in question. (The start-stop API is not worked out)
More information about the erlang-questions