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: [snip] > * Export GIMP internals through CORBA. [snip] > 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? Rockwalrus
