Re: getting started

[Havoc Pennington <rhpennin midway uchicago edu>]

On Thu, 27 Aug 1998, Felix Bellaby wrote:
> 
> gEdit is in the process of developing a plugin model that appears to
> be wholly application specific but the plugins do things like mailing
> or encrypting files. These operations should be implemented as CORBA
> servants for suitable interfaces. That way any GNOME application could
> use them. Given a interface from the idl stored in the interface
> repository to guile then these applications could use these plugins
> without ANY CODING by the application writer beyond support for guile 
> scripting. The end user would just attach a guile script that uses the
> plugin onto a menu item and Hey Presto!
>

This is a great idea! 

> Tom also wrote separately:
> > FYI, a standard technique for dealing with large data is to use CORBA
> > to negotiate a separate high-volume communications channel.  This gets
> > you the benefits of CORBA where it matters the most, and high
> > performance where that matters the most.
> 
> I do not understand Tom's intention here. Why should you implement
> CORBA in such a way that you need a separate channel for high-volume 
> communication? Why not implement CORBA to use the high-volume channel
> when it is available, say by putting the servant in a dynamic library?
> Do it another way and you lose one of the most important benefits of
> CORBA: the object model that it is designed to implement!! Programmers
> should not need to worry about how they get access to data in a CORBA
> environment. The standard is supposed to define how you gain that
> access: through the idl interfaces.
>

A Guppi plot object will need to get huge arrays of floating point numbers
and iterate over them - so this needs to be implemented somewhere, in
CORBA or not in CORBA. I think the first thing we want to CORBA-fy for
Guppi is the "array" object (DataSet from the Goose library; it will be
independent from Guppi and usable by any application to get statistical
services and import numeric data from text files, and will also be passed
to the plot objects, possibly in groups (tables)).

Goose doesn't even require glib so it is also convenenient to compile and
work on CORBAfying (hint, hint). If anyone is so inclined I imagine we
could get the latest version on CVS or otherwise available. 
 
> However, Havoc does not need this abstraction for his present
> purposes. So long as the interfaces provided by Guppi are all stuck
> into a single module then all he has to do is open that module in the
> interface repository and search through them. In mico this is done as 
> follows (the ORBit steps would be a straight C++ to C translation):
>
[cut] 

Looks reasonably straightforward, though I don't understand it all yet.
 
> This approach would limit you to the slowest possible connection to
> ORBit (i.e. the one available at the moment). However, the source that
> you wrote would require very few changes in order to make use of an 
> ORBit specific C++ idl compiler. In fact, it should require no changes
> at all providing you steered clear of any mico extensions.
> 

OK, this may be workable. The C bindings would work too but it's kind of
gross and seems pointless if the C++ bindings will be available in the
near future.

I think we may want to wait a few weeks on the CORBAfication of Guppi
until all of the needed services exist in remotely stable form and we've
had a chance to study it more. I am writing the C++ with an eye to busting
it up into dynamically discovered CORBA objects though.

In particular I think we need:
 - C++ bindings (well, this is more of a want than a need :-)
 - A fast way to pass these arrays of doubles around
 - A way to subscribe to events; e.g. changes in the 
   data, so that they can be reflected in the plot.
 - Enough stability that we don't have to hack ORBit
   on a regular basis.

Havoc