Scripting C++ -- 2 -- a more concrete example.

[Craig Maloney]

Donovan Rebbechi <elflord at panix.com> wrote in message news:<slrna7tidr.8aq.elflord at panix2.panix.com>...
> In article <3C7E6642.2030202 at physics.ucsb.edu>, Craig Maloney wrote:
> > If using a wrapper generator (e.g. SILOON) I don't see a way around the 
> > marshalling of the call to get at the atom data structure.
> 
> I don't really understand exactly what the problem is. 
> > 
> > Of course, this would be taken care of by a revamp of the design of the 
> > class library... maybe making the crystal an atom factory that produces 
> > new atoms in its own address space.  But I would like to avoid thinking 
> 
> Now I'm really confused. If you're not using CORBA, the atoms are in the
> same address space, aren't they ?

This is how I presumed that Boost also worked -- I must be mistaken.
After having seen yours and Ralf's comments, I now have the impression
that Boost works it's magic differently.

Perhaps Craig Rasmussen could enlighten us as to how SILOON deals with
co-location issues such as the one above?

>From the SILOON doc/design.html page :
-----------------------------------------
 The goal of SILOON is to generate bindings so that users can access
the functionality of an existing application or library from a
scripting language. In order to accomplish this, the essential
functionality of SILOON is separated into three separate modules:

   1. Client Interface.   The client script is responsible for calling
the client interface using a low level invoke function with the name
of the function to be invoked and with function parameters. The client
interface is responsible for translating the function name received
from the client into a function identifier (an integer), which is
associated with the requested function on the server. The function
identifier is marshalled into a buffer, along with function arguments
received from the scripting client. This buffer is then handed off to
the transport layer to be delivered to the compute server. On
completion of the function call, the transport layer returns the
buffer and the client interface is responsible for unmarshalling the
return value and passing it on to the client. The remote method
invocation is done synchronously with the client blocking until the
call has completed. The client interface also comprises user-friendly
script wrapper classes and an alias mechanism that lets the user
redefine names of functions.
   2. Transport Layer.  The transport layer is responsible for
delivering the argument buffer to the server and subsequently
returning the buffer to the client interface when the method
invocation has completed.
   3. Server.  The responsibility of the server is to unmarshall the
function arguments from the received argument buffer and then to call
the correct function. After the function has finished executing, the
returned value is marshalled into the argument buffer and the buffer
is returned to the transport layer.

--------------------------------------------------------------------------