Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise and Fall of CORBA (2006)

queue.acm.org

Post reply on HN
Print view View original

141–150 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#141

Post by sinuhe69 »

blowski wrote: post #63
tragomaskhalos wrote: post #60

Earlier quoted context omitted.

Well yes that's true, however that's in the spirit of a 3rd party providing a specific service to your program, whereas the object zealots intended objects in the sense of entities with identity being these off-the-peg consumables. Imagine if in a code review every time you declared a class to represent some feature you were challenged as to whether there wasn't some component you could shop for instead. The Aircraft…

What about when I install a library or use a framework? When I use Spring Boot, it's calling my code. I install libraries which dispatch events to which I subscribe and that come with pre-defined objects I pass around. I use SDKs to talk with REST APIs. I even use objects that persist their data in my database, and have their own migration files. I'm being somewhat disingenuous asking this. I realise most of the code…

Yes, it had became reality in many environments like .NET, Delphi and even Windows COM. The problem is however, they are only good in homogenous environments. Services on the other hand, could be easily consumed by all systems because they don’t need to know your system to work with and you don’t need to take care of the memory, threading and life cycle issues as you need to with objects.

In other words, it boils down to the objects vs interfaces, OO vs functional programming arguments in the last decades.

In reality, we still do both. But it’s clear by now that we don’t want remote objects anymore but remote services.

Re: The Rise and Fall of CORBA (2006)

#142

Post by eternityforest »

Animats wrote: post #122
eternityforest wrote: post #64

Earlier quoted context omitted.

I think negotiation can be a bad thing. Instead of just making a standard so a server can say "This server complies with the BuyCrap 2.0 protocol", and a way to discover this fact, people make up garbage like "This server has a method called AddToCart which takes a string and an integer in this range". The introspection mostly is used to ask "do you have this feature I already know about from the spec that really sho…

> about the same level of effort as just reading a REST API document anyway, at least for basic use cases. The idea is to automate that, using a LLM to read a description and create the appropriate reply messages, retrying until it works. You need at least a rough specification and semi-useful error messages. Then let the system work until it has established communication.

I think any LLM that could do that could probably do just as well with a badly written informal README, same as humans do.

Re: The Rise and Fall of CORBA (2006)

#144

Post by sirtaj »

tguvot wrote: post #139
inferiorhuman wrote: post #58

Earlier quoted context omitted.

Now there's a name I've not seen in a while. And, yeah, if memory serves CORBA worked well enough for Gnome but not KDE because the C++ story was not great. Whatever bindings being used were dependent on features not well supported by G++, templates being painfully slow to compile, etc.

if my memory serves me right, corba (if form of orbit) worked well enough for gnome because almost nothing used it. kde in it's turn were heavily reliant on it (mico) for embedding and communication. but compilation was indeed painfully slow (i still remember never ending kde compiles in 99-2000) so they came up with dcop/kparts after having few drinks and deciding that they can do better

Apart from the template bloat, at the time CORBA meant exceptions IIRC. The bits of GNOME that used orbit dealt with the same errors mostly by ignoring the return codes.

In the end, both teams decided that assuming components running in remote processes was the wrong default. I'm not sure what GNOME replaced them with, but KParts rescued KDE 2.0

Re: The Rise and Fall of CORBA (2006)

#145

Post by lelanthran »

naasking wrote: post #135
lelanthran wrote: post #123

Earlier quoted context omitted.

> Uh-huh, but did the message actually get through? Can they safely just retry? ... > The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow. They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls…

> They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls. The promise is at the remote end. Promise resolution is idempotent, so retries always resolve to the same value. These are correct promise semantics as pioneered in the E language.

> The promise is at the remote end.

What? The promise is local, so what do you mean "the promise is at the remote end?"

> Promise resolution is idempotent,

No. It is only run once (whether resolve or success), that does not mean it's idempotent.

Just like exceptions for synchronous code, or error returns.

Re: The Rise and Fall of CORBA (2006)

#146

Post by tguvot »

sirtaj wrote: post #144
tguvot wrote: post #139

Earlier quoted context omitted.

if my memory serves me right, corba (if form of orbit) worked well enough for gnome because almost nothing used it. kde in it's turn were heavily reliant on it (mico) for embedding and communication. but compilation was indeed painfully slow (i still remember never ending kde compiles in 99-2000) so they came up with dcop/kparts after having few drinks and deciding that they can do better

Apart from the template bloat, at the time CORBA meant exceptions IIRC. The bits of GNOME that used orbit dealt with the same errors mostly by ignoring the return codes. In the end, both teams decided that assuming components running in remote processes was the wrong default. I'm not sure what GNOME replaced them with, but KParts rescued KDE 2.0

yea. kparts were great. compilation went down from neverending to something reasonable. and konquerors ability to embed any other application (because they were written as kparts) was great.

in gnome i think they did something like "gparts" based on glib. but because gnome desktop was composed in large part from applications written in gtk and not in gnome libs it never had too much uptake (unlike in kde). but i might be wrong - i been kde user from 1.0 alpha4 and gnome was parallel universe

Re: The Rise and Fall of CORBA (2006)

#147

Post by [deleted] »

inferiorhuman wrote: post #58
sirtaj wrote: post #38

Earlier quoted context omitted.

KDE tried and discarded CORBA in KOM/KParts well before GNOME got around to putting it in production. DCOP was a response to CORBA's complexity and fragility, and was almost "reinvented" in the form of DBUS.

Now there's a name I've not seen in a while. And, yeah, if memory serves CORBA worked well enough for Gnome but not KDE because the C++ story was not great. Whatever bindings being used were dependent on features not well supported by G++, templates being painfully slow to compile, etc.

[deleted]

Re: The Rise and Fall of CORBA (2006)

#149

Post by naasking »

lelanthran wrote: post #145
naasking wrote: post #135

Earlier quoted context omitted.

> They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls. The promise is at the remote end. Promise resolution is idempotent, so retries always resolve to the same value. These are correct promise semantics as pioneered in the E language.

> The promise is at the remote end. What? The promise is local, so what do you mean "the promise is at the remote end?" > Promise resolution is idempotent, No. It is only run once (whether resolve or success), that does not mean it's idempotent. Just like exceptions for synchronous code, or error returns.

Nothing personal, but people not aware of where these concepts came from in distributed computing history is annoying, and I don't like repeating myself:

http://erights.org/elib/distrib/captp/index.html

Re: The Rise and Fall of CORBA (2006)

#150

Post by naasking »

stickfigure wrote: post #117
naasking wrote: post #99

Earlier quoted context omitted.

> A remote call fails, the error propagates up the call stack, and someone gets an error message. Uh-huh, but did the message actually get through? Can they safely just retry? These are very uncommon failure modes on local systems but very common on networked systems. Without a proper stateful abstraction beyond just "procedure call", like a promise, you can't address these failure modes properly. > In the rare case…

> you can't address these failure modes properly. Again, total nonsense. There's nothing special about a promise. Whatever logic you can build on promises is easier to build synchronously. Everything that applies to building distributed systems applies whether you use rpc stubs or promises. Promises are just noisier and harder to reason about.

Maybe we're speaking past each other. Idempotent operations are implicit promises. Network partitions require idempotency at some level to ensure robustness. That means any robust distributed protocol requires promises at the core protocol level.

Trying to hide the promises behind a synchronous client interface is unnecessarily constraining and inefficient, like requiring large stack contexts that can't be restarted or persisted, and so can't be simply resumed after partitions.

Post reply on HN