Re: CORBA performance - why ?

[Michael Meeks <michael peabody ximian com>]

Hi Havoc,

On 2 Dec 2001, Havoc Pennington wrote:
> Michael Meeks <michael peabody ximian com> writes:
> > ... you can also fairly easily create async
> > stubs / skels that allow a larger degree of non-blocking-ness ...
>
> Well sure, but then you are no longer network transparent. ;-)
> oneway/async are hacks that expose the details of networking.

        Assuming you're referring to the above; in fact the async calls go
via a UDS even in-proc - so in fact the network transparency is still
hidden; ie. you can do this in-proc:

        do_this_async (foo, "hello world", cb, user_data, &ev);

        and when you next hit the linc event loop or the glib idle loop
you'll get called back with your return values, out args or exception
data.

        We could trivialy architect oneway calls to do this in-proc, but
there is a certain efficiency penalty that is fairly unneccessary for most
things we use oneway for.

> The whole point I was making is that robust remote component usage has
> to care about the fact that the component is remote.

        No one is going to argue that for a highly distributed system you
don't need to design your interfaces sanely - you can just assume you're
local. But - what one might argue, is that if you design the interfaces
sanely for a fairly distributed case - they will work well in-process as
well, thus giving you flexibility.

> For example, there is no reason GConf _can't_ be implemented with
> CORBA - but really in the end the IDL _should_ have been something
> like:

        Um - why ? I really don't follow your logic; simply because you
can express your CORBA API in terms of a simpler CORBA API doesn't say
a whole lot to me.

        Perhaps also if you had used the ORB services which are there to
help you eg. CORBA's Any instead of the GConfValue union it would have
resulted in more code re-use - that in turn would make the task of
re-writing the ORB marshalers on top of a trivial IDL more daunting.

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers