Re: [RFC] External control of Octave via IPC

[John Swensen]

On Jan 20, 2009, at 5:21 AM, Michael Goffioul wrote:

> On Tue, Jan 20, 2009 at 10:15 AM, Søren Hauberg <address@hidden>  
> wrote:
> > I think we're misunderstanding each other. What I've done is very
> > similar to the octave_server class that John has written. The, IMHO,
> > problem with the octave_server class is that it is designed for
> > interacting with editors that are running in the same process as  
> > Octave.
> > I think that limits its usefulness, as many people (myself included)
> > will prefer to run their favourite editor in a different process. The
> > octave_server class will then not allow my editor to communicate with
> > Octave, as they are not running in the same thread.
>
> Now we understand each other :-)
> I was pointing out the possible redundancy. But your solution being
> more generic (because it allows inter-process interaction), I think
> this is a good point.
>
> Michael.

I guess I got to this conversation late, but it seems you guys have  
sorted it out.  It seems, as you said, that the idea is very similar  
except that it transfers data over the DBus IPC, rather than direct  
function calls and STL structures.

Would it be possible to define the same interface (not necessarily  
what is in the octave_server class right now) that returns data in the  
exact same way for both DBus and direct function call  
implementations?  I think an IPC method of interacting with Octave is  
important (think better distributed octave implementations, making a  
Octave Engine similar to the Matlab Engine, etc), but when running in  
the same process as Octave, it is altogether unecessary.

John Swensen