why isolated components

[Jay Nelson]

Joe wrote:

 > ... (deleted discussion of machines in different countries)

That description was much clearer.


 > Long live isolated components with asynchronous streams :-)

A while back I posted about looking into an algebra of streams.
I had a similar goal in producing a webserver (and later thinking
about a GUI) in that I wanted to have multiple components contributing
to the final output.  This takes two different forms:

1) HTML, XML, PDF, raw text, SOAP, etc:  there is one source which is
the content that is stored.  There are multiple "markups" or "formats"
which are layered on the content (or interspersed).  Depending on the
final output, multiple streams need to be combined by separate processes,
each of which contribute local knowledge of markup.  Allowing editing markups
means some things may get deleted, modified or merged.

2) GUI with multiple inputs (keyboard, mouse, microphone, 2nd keyboard, etc)
A Lampley clock is needed to globally timestamp the multiple streams so
that they can be merged into an interpreted view of the inputs.  I wanted 
multiple
users on different machines around the world to interact on a single display,
so just as meta-ctl-f or double-click mouse are combinations that require
overlapping time measures, overlapping inputs from different machines can
contribute to new behaviour on screen (or in audible music, etc).


The key to having multiple isolated processes is ensuring that the method of
interaction among the processes is rich enough to express useful constructs,
and formally described sufficiently to predict the information transfer 
that will
occur.  (It would also be interesting to investigate something that is too 
complex
to monitor formally, such as the information transfer going on between a mass
of neurons to produce adaptive, unpredictable behaviour but that would be a
different exercise.)


 > Isolation is an essential pre-condition for building fault-tolerent systems.

This is why I switched to erlang from Java.  After working with it a while 
building a
gameserver, I decided that the streaming things I wanted to do above
required multiple overlapping processes, load balancing and fault tolerance.
I thought about the way a webpage is written and wanted to separate the
content from the markup to allow versioning of modifications on both, as well
as transparent multiple views of the same content.  My thinking went towards
componentizing the document on the paragraph level and maintaining all the
snippets as separate DB items.  A paragraph from email becomes quoted
and reused on a webpage, but is only stored once so that the versioning
and attribution can remain.

I have concluded the simplest way to implement this is to use an "object -
oriented" approach (horrors, not this discussion again! -- bear with me).
I plan to implement an Aspect-Oriented approach that more closely resembles
the old Simula than any modern day OO system.  Here are the basic features:

1) Every object is a process
2) Objects communicate with messages
3) The "behaviours" or "methods" of an object are modules (aspects)
4) Any object may contain any set of aspects (no inheritance as we know it)
5) An "instance" is created by composing the aspects needed
6) Aspects may dynamically be added or removed from a process
7) Prototype stamping of instances provides a syntactic shorthand
for creating a collection of similarly configured items (traditional class
related instances)

<aside>
Note that all modern day inheritance-based implementations would
have to use prototype stamping and would suffer from "code bloat" in that
every instance would have a copy of the code.   In erlang this isn't a problem
because the code is shared (although across machines that is not the case),
and the enormous hit of inheritance across processes is impossible to accept.
Face it, inheritance was an optimization tradeoff of memory vs execution 
time --
the tables have changed since then and both are cheap.  The restrictions of
inheritance can be enforced in other ways if necessary.

Also note that objects no longer are required to belong to the same "class".
Each may have different behaviour.  I can have three chairs, one with 4
legs and folding capabilities, one with 3 legs no folding and a taller 
viewpoint,
and one with a pedestal leg and a curved seat.  They can all share the same
"seatable" aspects but have completely different other aspects.  As well, an
individual object can change its aspects over time just as certain species
of fish can be female or male at different times in their life.

You don't have to take advantage of the dynamism, but if it is not available
you find yourself in a straight-jacket.
</aside>

Joe later wrote:

 > My view is that
 >    1) We should construct systems from isolated components
 >    2) The systems should communicate with asynchronous messages
 >    3) The sequencing and types of these messages should be governed by 
contracts
 >    4) The contracts should be checked dynamically and all the time


The result is exactly what Joe is talking about, if the following extensions
are added:

8) Objects communicate using UBF messages
9) Programmers write aspects
10) Architects weave objects


 > We should also aim to improve the isolation bit - ie make Erlang etc better
 > to avoid malicious inter-process denial of service attacks.

This is the one thing about erlang that I thought was lacking, but I 
haven't thought
about how to improve it (I don't have the background knowledge).  I would
like to use erlang more as a P2P type system, but the whole notion of cookies,
how they are communicated and how to prevent spoofing is a bit scary in a
wide open world.


I like the idea of reusing proven code by hooking it with new code and letting
them talk to each other.  I don't like the idea of digging into Apache or gcc
and trying to add a feature.

jay