Re: [RFC] External control of Octave via IPC

[Søren Hauberg]

man, 19 01 2009 kl. 21:49 +0000, skrev Michael Goffioul:
> This sounds interesting, although somehow redundant with John's
> (Swensen) proposal to allow interaction between octave and an editor
> running in another thread (or another process?, I'm not sure). However,
> your idea is more generic, using DBus, so it's probably a better way
> to go.

John, please correct me if I'm wrong.

>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 just have 2 concerns:
> 1) portability: it seems DBus exist under Windows (MinGW and MSVC)
> under the name winDBus. Any idea about potential portability issues?
> Is winDBus in sync with reference implementation?

I'm not quite sure. From what I understand, it is slightly out of sync,
but this is mostly relevant if you use some of the more fancy features
of DBus (which I doubt we would need). So, I don't _think_ this is an
issue.

> 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.

Soren