[omniORB] A question about stub/skel class roles

[Aaron Van Couwenberghe]

Hi all

	I have just been looking at hacking omniidl to separate the client
stubs and the server skeletons in its output.

	I've heard a number of misconceptions lately, regarding the
client/server code for CORBA being inseparable. However, this is wrong. If
you have defined interface foo in IDL, after compiling that IDL you have
access to two sets of methods: one to acquire an object reference and
manipulate it (make calls etc) and one to link to the implementation.

	i think omni would benefit greatly by making this distinction; it
may be as simple as having omniidl spit its current output to two sets of
files rather than one largish one. So, I've listed every class that it
spews. Could someone comment on what each of these accomplishes, and what
their dependencies are (aside from subclassing, which is fairly obvious)?
Thanks!

class foo_Helper  // Perhaps both imp and client side?
class foo         // Implementation end, it looks like
class _sk_foo     // Implementation end
class _proxy_foo  // Gosh, I'm at a loss. I would guess imp end
class _nil_foo    // No idea. subclassed from class foo
class _lc_sk_foo  // Imp end with lifecycle support?
class _dead_foo   // Erm,.... subclass of foo, something to do with LC
class _wrap_home_foo // No idea from here out
class _wrap_proxy_foo
class _lc_proxy_foo
class foo_proxyObjectFactory

Gee, looking at the above, with my guesses, there wouldn't be that much of a
separation. Anyway, could someone tell me whether I'm right about this?  

I didn't spend a great deal of time poring over omniidl's output.

-- 
..Aaron Van Couwenberghe... ..vanco@sonic.net.. ..aaronv@debian.org....
	Berlin:			http://www.berlin-consortium.org
	Debian GNU/Linux:	http://www.debian.org

"...Nothing astonishes men so much as common sense and plain dealing..."
	-- Ralph Waldo Emerson