Re: On GIMP and CORBA

[Manish Singh <yosh gimp org>]

Well, this is sorta belated.. first chance I got to actually sit down and
think about things.

> The PDB as it stands currently could be just translated directly into
> a "procedure interface", so it is possible to provide compatibility
> wrappers for 1.* extensions in the new system. That, I think, won't be
> the first priority, though.

At that point, I don't even think compatibility is much of an issue at
all.
 
> There are performance considerations, of course. CORBA is likely to be
> somewhat slower than gimpprotocol. However, I expect the exported
> operations to be relatively high-level, so there won't be too many
> calls.

Where exactly are the bottlenecks with CORBA? Currently, the major speed
drag is plug-in tile communication, and it seems to be a shame to put all
that work in intelligent swapping and COW only to have it defeated at the
IPC level.

> One cannot do a global "change pointers to object references"
> translation in the core code, for that matter. I think that a sensible
> compromise is to have separate wrappers to most of the high level
> operations (such as on images and layers), which require and check
> that all its object arguments are local to its process, then retrieves
> the implementations (the actual object pointer), and passes those to
> the actual routines. Currently, only the gimp core actually implements
> images and layers, so this is not much of a restriction.
 
This is pretty much what's there already, since the PDB invokers do argument
validation and ID lookups already.

> Which brings to another point: mass data transfer. Extensions,
> especially filter plug-ins, require the moving of lots of image data
> back and forth. Currently, this is relatively fast, because shmem is
> used. Although CORBA by default supplies only a socket-based
> communication medium, I think we can either use shmem by hand, or
> (preferably) write a shmem-based GIOP implementation for ORBit.

Ah, ok, this addresses one of my previous concerns, at least somewhat.
 
> Alternatively, the extension could make a local copy of the entire
> image it operates upon and use the gimp operations locally (from a
> lib) on it.

I think this would be rather prohibitive on large images.
 
> The place where data transfer latency is absolutely essential is in
> brushes, because these have to be completely interactive. The idea is
> to make these distributed as well. I'm not sure whether it's possible,
> even with shmem, to achieve sufficient transfer speeds between address
> spaces. There has also been an idea of dynlinking the brushes to the
> core (here "core" probably meaning the process implementing the
> GUI). This wouldn't be a very portable solution, (though in systems
> that don't provide dlopen, this would simply mean the set of brushes
> is fixed at compile time, not a horrible restriction). Also, I don't
> know how this would interface with CORBA. Brushes are supposed to be
> scriptable, too, so they have to have some sort of external
> interface...

Well, gmodule addresses some of the portability concerns. But the speed
and flexibility is a real problem.

-Yosh