Re: [Evolution-hackers] work in progress white-paper on extensions

[Not Zed <notzed ximian com>]

On Mon, 2004-04-05 at 11:51 +0100, Michael Meeks wrote:
> Hi Michael,
>
> On Fri, 2004-04-02 at 18:52 +0800, Not Zed wrote:
> > > 	Of course - were I to believe that you actually understood what
> > > CORBA/Bonobo will do for you / what it's good at - I'd be most happy for
> > > you to go and re-invent big chunks of it in yet-another-way, requiring
> > > yet-another-binding.
> > 
> > So what will it do for me, and just what is it good at?
>
> 	Well - there are only really 2 nice thing about it is the type
> introspection stuff. Which allows you to write in C, using recursive C
> types (defined in IDL I admit) - and allows those methods to be remotely
> introspected by dynamic languages a-la Python. The other nice thing is
> that BonoboObject should make adding methods to an interface extremely
> simple in C. Oh, and I guess finally - since it's thread-safe, you can
> (presumably) add camel interfaces without over-much problem.

Well the one problem with this is that you still have to do all the mashalling from the C structs to the IDL structs (since for all but the simplest types, they don't map directly).  You also have to mirror all types or wrap their functionality somehow (e.g. objects).

I agree, the marshalling and particularly instrospection stuff is useful (marshalling isn't really much code).

One problem with CORBA is the granualarity of the interface.  It doesn't work well for fine-grained interfaces, and to, for example, wrap camel behind a corba interface you'd have to rearrange the interfaces somewhat for scalability and efficiency.  Much in the same way, for example, Camel turns a remote interface like imap into a local fine grained interface by caching a lot of stuff locally.

> > It certainly solves problems, but many don't seem to be ones we're after
> > having solved, or that map well to our application?
>
> 	Well - it doesn't solve the 'plugin' problem - there is still plenty
> of work that needs doing there along the lines you outlined; it would just be
> a pity to re-invent all the introspection / invocation stuff I guess. As you
> say, there are plenty of problems with it :-) such as reference counting etc.
> but most of those can be binned / ignored by a careful user.

Well I did have it in mind that you could use the same for a bonobo implementation too.  So you could use that for the interfacing bits if you wanted to.  The other stuff in the plan would need to be done anyway, so if you used bonobo as an implementation type (as 'shared library' is an implementation type) you would have very little overlap.  You'd just have to implement wrappers for the 'hook types', which is something you'd need to do anyway.

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.