Re: [RFC] External control of Octave via IPC

[Søren Hauberg]

tir, 20 01 2009 kl. 09:40 +0000, skrev Michael Goffioul:
> > >From what I understand John's work allows you to run an editor in the
> > Octave thread. So, if you want to integrate the Octave debugger in, say,
> > Emacs, you'd have to embed Emacs in the Octave thread (using Xembed?).
> > This is non-trivial and non-portable. What John's done is to create a
> > new editor (based on gtksourceview, so it's not very much work)
> > specifically for Octave, that run's in the Octave thread.
> >
> > This makes very good sense, but it does not allow users to use their
> > editor of choice. This basically means that us old farts that aren't
> > going to changing editor won't have access to debugging facilities in
> > the editor.
> 
> I was actually referring to something else. To enable his editor to interact
> with octave, John wrote a small class (I think it was called octave_server)
> to allow an external component (like an editor, running in another thread)
> to communicate and exchange data with octave. The idea was the same:
> hook an input event into the readline loop and process events from there.

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.

> >> 2) does DBus allow in-process communication, between threads for instance?
> >> (sorry for possible stupid question, I know nothing about DBus, except that
> >> it implements IPC).
> >
> > I guess you could use DBus to communicate between threads, but it would
> > a fairly complicated way of doing that, and it would be quite
> > inefficient. So, if the general opinion is that we should be running the
> > editor in the Octave process, then I don't think DBus would be the right
> > solution.
> 
> I don't agree. My point was that a good solution would allow communication
> with octave from another thread (even if it's not that efficient) or
> another process,
> using the same consistent interface. If DBus can do that, then I think
> it's a good
> candidate. We don't need high efficiency here. But a unique interface would
> make life easier.

Yeah I guess you have a point.

Soren