6 ms·

If not for TBL and Roy Fielding, these words would still mean something to people, and we would all be worse off.

bexsella 3y ago
Unfortunately I know exactly what CORBA means. Helming a legacy project that still contains the requirement of using CORBA is a real bugbear of mine. It takes non-trivial effort to even build the ORB we use (OmniORB) for each platform we support (the number is low, currently 4) that its effectively the only library we don't build from source each time. Every now and then, someone struggles to build it, we then check in the built libraries and forget about it for as long as we can.
- chris_wot 3y ago
  Isn't that a problem with OmniORB and no CORBA?
  - bexsella 3y ago
    I started writing then went on to automatically vent. I extend my apologies for wasting everyone's bandwidth. There are better technologies to use that can do pretty well everything that CORBA offers. That's the source of my general frustration, OmniORB just extends that frustration.
    - chris_wot 3y ago
      Nah, not a waste of time - I understand the feeling!
    - adev_ 3y ago
      > extend my apologies for wasting everyone's bandwidth. No excuses needed, it is still informative. Curious question: What are the technical/political reasons to keep ORB/Corba in your project right now ?
      - bexsella 3y ago
        There's no strict technical reason for keeping Corba around. It's primarily an issue of finance. Where I work there's no real way to get funding for a maintenance task if it doesn't directly relate to a specific project (we produce a product that is utilised by various projects, and through those projects get the funding for new features, and maintenance). There's no external call to not use Corba, so we will continue to use Corba. This is now a compounding issue, the tool that uses Corba was initially quite standalone but managers started pushing the tool as an interface to the embedded system I actually work on, this has resulted in more tools utilising Corba.
  - skissane 3y ago
    I suspect it is related though - CORBA is a zombie technology, so a lot of the code related to it is old and crusty, predates contemporary best practices, etc - and all that could be fixed, but its status as a dying technology means almost nobody has the motivation to spend the effort to fix those issues (anyone hit by them is likely going to decide that time and money is better spent replacing CORBA than improving their CORBA implementation), and as a result many of those issues will likely never get fixed
    - p_l 3y ago
      More that most of the better quality stuff is proprietary, and often mixed with somewhat specific environments with specific kinds of clients... and thus not really supported in the open. A lot of the time I'd say CORBA and related stack (DDS, for example) is better than what came to replace it, depending on the task :/
stefan_ 3y ago
DCE/RPC is used today! Lots of factories running this crusty stuff to interconnect PLCs: https://wiki.wireshark.org/PROFINET/IO https://wiki.wireshark.org/PROFINET/IO My favorite part of RPC is that it has a header with switchable endianness and a field for what floating point encoding you would like to use. For when your machine encodes Cray-compatible: https://pubs.opengroup.org/onlinepubs/9629399/chap14.htm https://pubs.opengroup.org/onlinepubs/9629399/chap14.htm
- p_l 3y ago
  DCE/RPC is basis for DCOM as well. And honestly, Profinet is one of the best fieldbuses out there (DCE is used in the setup phase, afterwards it's pretty much always raw ethernet though there's UDP mode documented somewhere).
  - skissane 3y ago
    > DCE/RPC is basis for DCOM as well. I wonder how interoperable DCE/RPC and MS-RPC are though? I mean, if I have a DCE implementation (for example IBM Encina), can I successfully talk to it using the MS-RPC client and server libraries bundled with Windows?
    - pjmlp 3y ago
      Maybe back in Windows 9X days, nowdays the protocol has evolved enough that I seriously doubt it.
      - p_l 3y ago
        The main issue is that MSRPC runs DCE over SMB named pipes - so one can't just take random DCE implementation and make it talk to NT's. But AFAIK once you get onto named pipe transport, the protocol at worst got extended but not changed too much (new crypto options mainly, iirc?)
        pjmlp 3y ago
winter_blue 3y ago
I’m sorry, what’s TBL? And when you refer to Roy Fielding, do you mean REST is much better than CORBA/DCOM/etc.? On REST, all I can say is that while it’s okay, I’ve been using GraphQL pretty much exclusively for the last year, and it’s been quite superior to REST.
- grzm 3y ago
  Tim Berners-Lee https://en.wikipedia.org/wiki/Tim_Berners-Lee https://en.wikipedia.org/wiki/Tim_Berners-Lee
- deleted 3y ago
  [deleted]
- talideon 3y ago
  GraphQL is orthogonal to REST. GraphQL is a query interface, nothing more. Now, if you (incorrectly) conflate HTTP and REST, I can see how you'd make this mistake given the limits on URL length, but even then there's absolutely nothing preventing a GraphQL query being serialised as a URL.
deleted 3y ago
[deleted]
pjmlp 3y ago
I disagree, given the tooling and how REST, graphQL and gRPC are a mess of lego blocks put together via clunky tooling without structure. Also the reason why Google had to come up with gRPC, kind of proves the point how HTTP based protocols don't meet the performance demands of those protocols. Also why Linux distributions use D-BUS, Android has Binder, Fuchsia FIDL, and Apple platforms XPC.
- DeathArrow 3y ago
  Let's not forget Cap'n Proto.
  - pjmlp 3y ago
    Sure, and there are yet others that I surely forgot.
_glass 3y ago
Laughs in Google's Protobufs

Unfortunately I know exactly what CORBA means. Helming a legacy project that still contains the requirement of using CORBA is a real bugbear of mine. It takes non-trivial effort to even build the ORB we use (OmniORB) for each platform we support (the number is low, currently 4) that its effectively the only library we don't build from source each time. Every now and then, someone struggles to build it, we then check in the built libraries and forget about it for as long as we can.

chris_wot 3y ago
Isn't that a problem with OmniORB and no CORBA?
- bexsella 3y ago
  I started writing then went on to automatically vent. I extend my apologies for wasting everyone's bandwidth. There are better technologies to use that can do pretty well everything that CORBA offers. That's the source of my general frustration, OmniORB just extends that frustration.
  - chris_wot 3y ago
    Nah, not a waste of time - I understand the feeling!
  - adev_ 3y ago
    > extend my apologies for wasting everyone's bandwidth. No excuses needed, it is still informative. Curious question: What are the technical/political reasons to keep ORB/Corba in your project right now ?
    - bexsella 3y ago
      There's no strict technical reason for keeping Corba around. It's primarily an issue of finance. Where I work there's no real way to get funding for a maintenance task if it doesn't directly relate to a specific project (we produce a product that is utilised by various projects, and through those projects get the funding for new features, and maintenance). There's no external call to not use Corba, so we will continue to use Corba. This is now a compounding issue, the tool that uses Corba was initially quite standalone but managers started pushing the tool as an interface to the embedded system I actually work on, this has resulted in more tools utilising Corba.
- skissane 3y ago
  I suspect it is related though - CORBA is a zombie technology, so a lot of the code related to it is old and crusty, predates contemporary best practices, etc - and all that could be fixed, but its status as a dying technology means almost nobody has the motivation to spend the effort to fix those issues (anyone hit by them is likely going to decide that time and money is better spent replacing CORBA than improving their CORBA implementation), and as a result many of those issues will likely never get fixed
  - p_l 3y ago
    More that most of the better quality stuff is proprietary, and often mixed with somewhat specific environments with specific kinds of clients... and thus not really supported in the open. A lot of the time I'd say CORBA and related stack (DDS, for example) is better than what came to replace it, depending on the task :/

stefan_ 3y ago

DCE/RPC is used today! Lots of factories running this crusty stuff to interconnect PLCs: https://wiki.wireshark.org/PROFINET/IO https://wiki.wireshark.org/PROFINET/IO My favorite part of RPC is that it has a header with switchable endianness and a field for what floating point encoding you would like to use. For when your machine encodes Cray-compatible: https://pubs.opengroup.org/onlinepubs/9629399/chap14.htm https://pubs.opengroup.org/onlinepubs/9629399/chap14.htm

p_l 3y ago
DCE/RPC is basis for DCOM as well. And honestly, Profinet is one of the best fieldbuses out there (DCE is used in the setup phase, afterwards it's pretty much always raw ethernet though there's UDP mode documented somewhere).
- skissane 3y ago
  > DCE/RPC is basis for DCOM as well. I wonder how interoperable DCE/RPC and MS-RPC are though? I mean, if I have a DCE implementation (for example IBM Encina), can I successfully talk to it using the MS-RPC client and server libraries bundled with Windows?
  - pjmlp 3y ago
    Maybe back in Windows 9X days, nowdays the protocol has evolved enough that I seriously doubt it.
    - p_l 3y ago
      The main issue is that MSRPC runs DCE over SMB named pipes - so one can't just take random DCE implementation and make it talk to NT's. But AFAIK once you get onto named pipe transport, the protocol at worst got extended but not changed too much (new crypto options mainly, iirc?)
      - pjmlp 3y ago

winter_blue 3y ago

I’m sorry, what’s TBL? And when you refer to Roy Fielding, do you mean REST is much better than CORBA/DCOM/etc.? On REST, all I can say is that while it’s okay, I’ve been using GraphQL pretty much exclusively for the last year, and it’s been quite superior to REST.

grzm 3y ago
Tim Berners-Lee https://en.wikipedia.org/wiki/Tim_Berners-Lee https://en.wikipedia.org/wiki/Tim_Berners-Lee
deleted 3y ago
[deleted]
talideon 3y ago
GraphQL is orthogonal to REST. GraphQL is a query interface, nothing more. Now, if you (incorrectly) conflate HTTP and REST, I can see how you'd make this mistake given the limits on URL length, but even then there's absolutely nothing preventing a GraphQL query being serialised as a URL.

deleted 3y ago

[deleted]

pjmlp 3y ago

I disagree, given the tooling and how REST, graphQL and gRPC are a mess of lego blocks put together via clunky tooling without structure. Also the reason why Google had to come up with gRPC, kind of proves the point how HTTP based protocols don't meet the performance demands of those protocols. Also why Linux distributions use D-BUS, Android has Binder, Fuchsia FIDL, and Apple platforms XPC.

DeathArrow 3y ago
Let's not forget Cap'n Proto.
- pjmlp 3y ago
  Sure, and there are yet others that I surely forgot.

_glass 3y ago

Laughs in Google's Protobufs