Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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 [expletive deleted], 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!"
|
