The wrapper project

[Joe Armstrong]

  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
this:

   +------------------+
   |   +----------+   |
   |   | 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
	         2   stop
		 3   play movie (file name in bytes 2..)

  etc.

  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
process).

  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
are available.

  (If anybody cares to write a C++ UBF parser/deparser I'd be very grateful)

  So do we have some volunteers -

  /Joe

  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)