This document is a high level overview of the Fuchsia Interface Definition Language (FIDL), which is the language used to describe interprocess communication (IPC) protocols used by programs running on Fuchsia. This overview introduces the concepts behind FIDL — developers familiar with these concepts already can start writing code by following the tutorials, or dive deeper by reading the language or bindings references.
Some light reading going into the weekend. Knowing how Fuchsia works might become quite important for developers over the coming years.
Cof, cof… CORBA… cof, cof…
Shhhhh, don’t say such things because you might give these young kids the idea that they aren’t the great innovators they think they are.
dekernel,
Haha, yeah it’s all been done before.
Although after what happened with java, google probably has reservations about using someone else’s tech. Nobody expects this of “open” standards and languages, but the devil is in the details. You never know when someone could buy up the rights and take you to court, 🙁
Note I have no reason to believe there’s any malicious intent from OMG. I’m just pointing out that google rolling their own could be “a form of insurance against possible future negative repercussions”.
https://en.wikipedia.org/wiki/Cover_your_ass
Jokes aside, CORBA has, in my opinion, too many design flaws and too much complexity as to be practical, so I can understand why Google went into designing its own ORB. But the similarities are extreme.
rastersoft,
Yes. Language authors want to write their own for whatever reason, but we end up having many different incompatible solutions that more or less accomplish the same thing,
https://www.guru99.com/comparison-between-web-services.html
I kind of think there is benefit in having one universal standard, but no one agrees on what it should be. CORBA is rich but complex, not to mention its licensing was sometimes unpalatable. SOAP would make it compatible with all the .net languages, but many developers dislike XML, I don’t like it either. Java has got it’s own, fuchsia will have it’s own. What really makes these “complex” or “easy” is language integration. These are easy to use when they are built into the language toolchain but they become difficult when you have to manually define and hook them up yourself.
I think the solution is clear, we need an assembly language of sorts for IDL, not for humans to interact with directly, but for compilers to produce and consume between themselves much like object files are. This way developers don’t really have to think about IDL much beyond using the function prototypes of their language.
This would be great for everyone, however there’s a big problem: some of our most popular languages (ie C/C++) have no concept of reflection and consequently the tooling is always going to have to be supplemented with manual IDL generation, which is very tedious. Manual integration is what makes CORBA such a pain to impliment. Since C/C++ aren’t going anywhere, a universal standard that isn’t a pain to implement may be untenable.
Here’s an interesting article on “The Rise and Fall of CORBA”…
https://queue.acm.org/detail.cfm?id=1142044
More than license it’s more likely because FIDL is intended to be used between local processes instead of distributed like CORBA (COM vs DCOM).
This is probably an evolution of Google’s protocol buffers.
jgfenix,
That’s interesting, but I’m not quite sure how to interpret that. COM components were in-process while DCOM was the protocol used for remote out of process calls. DCOM was typically used for IPC on the machine (which is how we used it), but it was capable of being bound to remotely accessible sockets.
https://networkencyclopedia.com/com-component/
My impression was that FIDL’s IPC is more like DCOM than COM. Do you think FIDL is not network capable? Why would that be? You could be right considering that Fuchsia targets mobile applications and not middleware, but it seems like an arbitrary restriction for IPC to not work remotely (unless it’s just a matter of policy?)
I suspect FIDL is going to be used in the exact same way as AIDL with the same capabilities. I’m not an android dev, is Android’s AIDL limited to local IPC only or is it possible to bind to a network socket?
https://developer.android.com/guide/components/aidl
Replying here because of threading limitations ; @Alfman FIDL’s communications interface under the covers is bound to a Zircon kernel channel. As far as I’m aware, those don’t currently have a means to communicate off-box. I’m not sure how likely that is to change since drivers and consequently networking in Zircon/Fuchsia are in userspace.
anevilyak,
Thanks, this is informative.
I came across these links, which suggest google themselves have already had reason to work around the limitation for certain use cases, but it seems like they’re proxying the calls indirectly.
https://fuchsia.dev/fuchsia-src/development/tools/ffx/development/plugins
https://cs.opensource.google/fuchsia/fuchsia/+/main:sdk/fidl/fuchsia.developer.remotecontrol/remote-control.fidl
So FIDL is probably not going to be viable for normal RPC applications unless they extend it. This could be an annoying limitation for middleware applications, but for mobile phones probably nobody cares and RPC would end up being firewalled so it wouldn’t work anyways.
Probably not CORBA they’re reacting to. Likely more of a reaction to the IPC implementations in Android: DBUS and BINDER. But I know DBUS was influenced by CORBA, so there’s likely some thought around similar concepts.
Having not used IPC on Android, I’m not to be listed to closely, but this article puts it more in perspective. Android used its own Aidl (Android interface definition language) that then used Binder underneath. So FIDL is maybe similar but for Fusia. In any case not CORBA ( which my brain has always wanted to spell as COBRA due to GI JOE infecting my brain as a youngster).
https://developpaper.com/fidl-a-new-way-for-flutter-to-communicate-with-native-data-not-limited-to-basic-data-types/
Ima dork just realized thats flutter not Fushia. :/
One of my former lecturers rolled up at my office looking for piecemeal work in the mid-90s, he was semi-retired and building himself a little side-gig developing web based applications. Mostly small bespoke database stuff for industry. He was big on CORBA and loved hiding in corners doing theoretical stuff free of disturbances, when I mentioned I was doing a lot of client-server stuff in Java I recall him ever so clearly and confidently advising me that Java was dead!