SIMPL open source project... / Send/Receive/Reply message passing

[bob]

On Thursday 22 June 2006 01:57 pm, Jason Spiro wrote:
> On 6/22/06, bob <ican-rZHaEmXdJNJWk0Htik3J/w at public.gmane.org> wrote:
> > The SIMPL open source project aims to bring Send/Receive/Reply (QNX
> > style) message passing to Linux.
>
> Excuse my ignorance, but what is Send/Receive/Reply message passing?

There is a brief description of S/R/R on the SIMPL project website at:

http://users.netrover.com/~ican/simpl/srr.html

and also at:

http://users.netrover.com/~ican/simpl/simpl_paradigm.html

In reality the SIMPL API is really just 5 main functions:

        name_attach() - to register a process name
        name_locate() - to open a communication channel to a process found by 
name
        Send() - throw off a message and wait for a response
        Reply() - respond to a message
        Receive() - wait for a message to be thrown your way

In my view API's can't get any easier than that.

In reality if you've ever coded a simple function you've already used S/R/R 
albeit within the confines of a single process and using the stack as a 
message transfer medium.    However,  all the elements of an S/R/R 
transaction are present in a function call.   The function name is the 
equivalent of the SIMPL name.   The main code outside the function is 
equivalent to the SIMPL sender ... the act of calling the function the 
equivalent of a name_locate() and a Send() wrapped in one.   Once the 
function is called,  the code execution "blocks" waiting for the function to 
execute and return ... the return in the function is the equivalent of a 
Reply().   Upon that function return the main code (equivalent to SIMPL 
sender) unblocks and resumes execution.    The function code itself is 
equivalent to the SIMPL receiver ... with the function definition line being 
the equivalent of a SIMPL Receive().   The function code can be thought to 
"block" waiting for some code to call it.  

The only aspect of SIMPL which doesn't have an analog in the function call 
scenerio is the name_attach() ... although starting up the executable might 
be the equivalent of that.

If you continue with the analogy the softwareICs in SIMPL are like objects in 
an OOP program with full encapsulation and methods ... albeit without all the 
fancy inheritance capabilities.

What SIMPL does is expand this notion of blocking "function calls" to the 
sphere of interprocess communication.    This allows for good encapsulation 
and deployable executable testability as well as the possibility to disperse 
those executables transparently across any networking medium unchanged. 

In addition you can write your SIMPL modules in whatever language is most 
appropriate,  with the choice of C,  C++,  JAVA,  Tcl/Tk or Python at last 
count.    Furthermore a SIMPL application can easily consist of modules 
written in different languages and as long as they agree on the message 
format they can happily coexist and cooperate.

Finally,  in the case of Tcl/Tk the SIMPL paradagm has been extended 
transparently across OSs.   ie. Tcl/Tk SIMPL code can run and Windows and 
talk to other SIMPL code on Linux ... or in at least one instance directly 
into a deeply embedded network appliance.

QNX was the first commercial OS to embrace this S/R/R paradigm for 
encapsulating complexity of software applications.    They did this way back 
in the very early days of PC's in the early 80's.   In fact QNX predates 
Microsoft.

While SIMPL doesn't have the all the polish, raw speed and feature set of a 
QNX,  it is certainly "good enough" for lots of sophisticated applications on 
modern processors.

bob
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml