Re: CORBA vs. XML (was: Re: XML.COM: How I Learned to Love daBomb)

[Paul Tchistopolskii <pault12@pacbell.net>]

> Obviously, using XML makes it human readable; but I think the biggest
> difference is that the latter two are merely method invocation (and that's
> *easy*); while CORBA implements "remote objects", and the horror of issues like
> maintaining state, remote memory management etc and so on.
 
> Have I got that right?

I think yes.
 
> Stateful objects turned out to scale terribly, so it was all a waste of effort
> anyway.  The simpler, less powerful approach of mere method invocation is
> actually much better.

Strange. I think that anyone,  who've  tried writing 
some more or less complex HTML/CGI based GUI
application usually comes to conclusion that stateless 
protocols ( CGI ) are 'really good' only for "hello world" 
kind of applications.

It is all client/server. If MS would not kill Java RMI 
in the browser ( they have not shipped the rmi.zip 
with MS IE ), I think there would be almost no 
HTTP / CGI combos in this world - long 
time ago.

Sorry, if I don't  understand your point. 

I think there was a heaven already.
It was Java in the browser + Java RMI. 

I know, I know. Java sucks, e t.c. Sure. 

Rgds.Paul.

PS. Of course, it is always possible to knock
together some custom serialization, keeping 
the state between CGI invocations. Try to 
explain to some hardcode C developer that 
all his problems and bugs with malloc() are 
avoidable with garbage collector. 

He'd say : "Oh, no!  I like it the old way!
I keep gluing my serialization libraries to 
stateless CGI's because everybody 
does it!"