Re: Octave 3.0 plotting API/interface

[Herman Bruyninckx]

On Fri, 28 Feb 2003, N Smethurst wrote:

[...]
> My interest here is to try to provoke an interesting, constructive and
> hopefully fruitful discussion on the subjet of a common communication method
> between Octave and plotting/visualization/gui software in general. At best,
> such a method would be graphics package independant, allowing the user to
> easily drop in whatever package she desires, knowing that all her old
> scripts and functions will continue to run correctly with the new package
> (assuming it conforms to the Octave specification).
[...]
> Does anyone find this idea appealling?

I do :-) (My personal motivation is to have a plotting/visualisation
interface not to a numerical program such as Octave, but to a robot
control system. The requirements remain exactly the same though.)

My personal opinion: if you really want to make a generic plotting
interface, look at how to specify a CORBA plotting component. This would
ensure complete independence of whatever numerical processing software.
Aiming high and working towards something that might eventually be
strong enough to be accepted as an OMG/CORBA standard is the only way to
go: all other efforts will remain tied to one particular application.

So, I guess one needs specs for:
- data sets:
  + in batch, or streaming in one by one.
  + identification of what each part of the data means, including meta
    information such as physical units, time synchronisation, etc.
- generic plotting functionalities
- a "component interface" of the data generating application as well as
  the data visualisation application. (And maybe the application
  programming interface is a third component.)
  "Component interface" is well-defined in CORBA, which differentiates
  between several types, according to whether or not they have a
  "persistent state" (= come up after reboot in the same state as before)
  or not, and an identity (= applications know the name of the component
  they ask services from) or not.
- name serving (this is also part of the CORBA spec).
- "funtionality browsing": each component in the system (numerical
  processing, visualisation, programming, ...) can answer calls asking
  about the services it can provide.

Depending on your taste, you could call this design octave.NET :-)

Herman Bruyninckx

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480