On 18 Feb 2001, Miguel de Icaza wrote:
> Bonobo support could come in many different shapes.
> A 60,000 feet picture of Bonobization could include:
> * Export GIMP internals through CORBA.
> On exporting internals trough CORBA
> The idea behind this is that the GIMP engine,
> would be exposed through CORBA and it could be
> scripted remotely through any of the languages that
> support CORBA.
> Using the Bonobo support also means that in the
> future (we are working on some of this) the GIMP
> engine could also be exposed through SOAP.
> Although the GIMP is already scriptable internally,
> I believe there is no support for just using it
> remotely. With Bonobo you can mix various
> components and script them all at the same time.
> For example, you could use the output from a
> computation in Gnumeric to generate a graph in Guppi
> and then mix it up with some background in the GIMP
> and produce graphs from this ;-)
I personally have wanted to see this for a while. Right now the gimp
plug-in protocol is highly asymetric -- the gimp itself is a special case
and must be present. Furthermore, the gimp process must be the one that
runs the plug-in executable. While I think it essential that we keep the
plug-ins in a seperate process space from the images themselves (plug-ins
may crash, but we don't want them to take down the images representing
hours of work with them), I also think more flexiblity would be a good
thing. The gimp binary itself would just hold a few interface items, and
any program could use CORBA to run gimp functions.
Having plug-ins available to run on other hosts would be nice. Think a
gimp farm. CORBA would seem to be an ideal solution to all of these
issues. Can CORBA handle the large amounts of data transfer gimp
requires at least as efficiently as the gimp protocol does?
Gimp-developer mailing list