Re: RFC: Using Standard C++ library components in Octave

[Greg Troxel]

I think the hardest part is figuring out what the semantics of the
interface should be.  I think many of your list changes are needed
since they reflect making octave usable as a reentrant library rather
than adding CORBA.  Allowing the daemon to initialize itself on
startup making the repl be a procedure call, and allowing for multiple
environments are all needed.

So, a client would call

  Octave::new()

and be returned a CORBA object which is a handle for a new top-level
environment.  Then, there would be calls to evaluate a statement,
returning the result, and probably some way to do something like
'load', but with the file being passed across the interface rather
than read from a file, and a corresponding save call.  This would be
used by programs that store octave files embedded in data files for
e.g. a document.

With CORBA, the servant created in the octave process to instantitate
the interface can contain the namespace ID, so no explicit passing of
namespaces is needed.  The new operation in the server allocates an
object, and the reference returns to the client refers to that object
in the server.  If the using program wants to share a namespace, it
can transmit the CORBA reference to a third program.  (This approach
avoids the issue of "what if one program wrongly executes a call on
another's namespace", although the notion of multiple users in one
octaved daemon process conjures up MLS nightmares very quickly.)
In the GNOME world, security is usually handled by having the daemons
run as the user, and all communication on a mode 700 AF_UNIX socket.

In general the approach for CORBA is the same for other scripting
calls, and will consist of two main tasks in addition to explicit
representation of multiple execution contexts.

  * factoring out I/O to procedure calls (as you discuss), decoupling
    the processing itself from the input and output

  * thinking about data representation.  octave prints matrices in
    a way intended for humans to read.  For a CORBA interface, as
    opposed to a remote GUI, there should be a way to return typed
    data itself, rather than a printed representation.

Signal handling and related issues are probably one of the more
difficult tasks.  CORBA procedure calls are naturally synchronous, and
one is pushed to use threads.  For long-running computations, one
could have an interface "computation_token =
Octave::start_compute(stuff)", a way to then obtain the result or
status, a way to ask for a notification callback, and a way to kill
computations.  This could let someone use a program to request a
computation and come back later to retrieve it, perhaps on a different
desktop session.  This starts down the path of the server being able
to save intermediate state.

For further info, I suggest reading
 http://developer.gnome.org/arch/component/bonobo.html
 http://www.gnome.org/gnome-office/bonobo.shtml

You of course don't need to use bonobo, but I do recommend
understanding it before declining to use it.  In particular, gnumeric
(spreadsheet) uses bonobo to embed guppi, and this is probably the
most similar usage.  Guppi has some octave-like features in support of
plotting.

  http://www.gnome.org/projects/guppi/
  http://www.gnome.org/projects/guppi/features.shtml

Another possibly related effort is GSL, for which guile bindings are
now available:
  http://sources.redhat.com/gsl/
  http://www.nongnu.org/guile-num/
  http://sources.redhat.com/ml/gsl-announce/2002/msg00009.html
I realize that of course GSL was not around when octave started, but
another refactoring rampage would be to use GSL (which can use ATLAS).

I suspect that making octave scriptable from guile in the above sense
would enable near-trivial CORBA-ization via 'guile-gobject', which is
not quite baked but seems to be coming along.  Guile-gobject is guile
bindings for glib/gtk-2.0, and enables writing CORBA client and
servers without having to write any C glue code.

        Greg Troxel <address@hidden>