* It talks a lot about containers, but this is really just contracts across systems, whether they run in containers or not. So not sure why the word "container" is necessary.
* It says "towards a type system", but then just muses about IDL/REST/Thrift, says "we need cross-system stuff ... so we should use better types", ...but...what does that look like? There are vague assertions that "we've done this", but I don't see any description of what that actually looks like.
* The Zookeeper/Kafka example, while apt, I'm not sure if "having a cross-system type system" is exactly right, as Zookeeper is purposefully/validly ambivalent about what its clients encode within it's file system, so whether the replication data is F/F+1/whatever is meaningless to Zookeeper. So to me the solution is not "cross-system type system" where Zookeeper becomes aware of Kafka's invariants, it's just Kafka itself correctly/internally interpreting the Zookeeper data. If that means it's an Either[ValidCluster,InvalidCluster] within the Kafka "ClusterInfoApi" abstraction, that's fine, but that's not something the Zookeeper API/IDL is going to care/know about.
* You're never going to get all networked services to agree on the One True networking format/One True type system/IDL, so why even muse about this as a possible approach?
Disclaimer I don't read academic papers on a regular basis.
FaaSlang uses static analysis and a superset of ESDoc comments to infer types for the API interface to serverless functions on our system. This allows for automatic type coercion from query parameters, automatic error checking, and more - all caked in at the gateway layer before a function is executed.
I've noticed a growing trend of startups trying to do this, and it just annoys me immensely. How hard is it to invest in your own original brand?
From the inception of the product we knew we were building a library - well, a publishing and hosting platform combined - but really, a library of APIs. The very first name we came up with was “stdlib” and, through a stroke of fate, “stdlib.com” was available.
We don’t take the name lightly. We understand we stand on the shoulders of giants, and it is our responsibility to create the best “stdlib.com” we can. It motivates and inspires our team members. That is why we chose the name.
It’s unfortunate you have a problem with this, but we’re very thankful to our developer community, team, partners and our investors for their support. :)
maybe everyone who thought of that name before you laughed and said "I'm not that kind of person"
I just went through this a bit and it doesn't appear that the specification allow for polymorphism in the type system. Am I missing something here?
If that's true, it doesn't seem to address the issues highlighted by the paper, although does handle simple type checking across interfaces of primitive types.
You also pay a nominal fee per ms of compute used when somebody uses an API you’ve built.
But you can get started for free - $5.00 of credits included that should cover up to 100,000 requests, if you’re really experimenting feel free to message our team (my email is in my profile here, I think).
Part of the point of the paper is assuming non-uniformity between APIs, hence the IDL.
I'd love to see this in an event sourcing context too. This paper, “The Dark Side of Event Sourcing:
Managing Data Conversion”, seems to hint at there being some interesting algebraic foundations to splitting and merging streams, adding new fields, etc: http://files.movereem.nl/2017saner-eventsourcing.pdf
And on the server side, the WSDL was automatically generated from your code if you used .net, so every time you would update the API the WSDL was up to date.
All that created a lot of plumbing and chatty XML traffic behind the scene, so the underlying exchange isn't as neat as a REST API, but as long as you didn't have to deal with it directly it didn't really matter.
lambdas/kafka: from my perspective, this one is kind of conflating the value of Options with the value of a typed IDL with some notion of generics baked in. It’s not clear to me that Option[Number] is what I’d want in this scenario, maybe I just want to reject anything that doesn’t validate to a Float — but I think that’s kind of tangential to whether or not generics in a more conventional sense would be useful.
edit: I guess I would have liked to see examples that show how this would help with discoverability, code generation, distributed tracing, monitoring, verifying large systems of microservices. It's a nice position to start with though -- are you planning on a follow up or an implementation?
As I suspected, the slides I dug up indicated they built it with some rigor but not high assurance itself. Probably too complex: the very reason I object to CORBA. Like you said, though, CORBA did have successes with this one in very-demanding niche in terms of predictability and security.
S-expressions are the oldest serialization format that I know of. ASN.1 is a fairly ancient IDL that was used for RPC back in the early 80s (ISODE/ROSE). There's ONC RPC, with XDR as the IDL. There's DCE RPC (and MS-RPC). And many many many many others. There's tons of serialization formats, and they all tend to have one or more related sort of RPC frameworks, ad-hoc or otherwise. Perl5 has several, no?
This is the space of NIH.
Take protocol buffers. It's supposed to be an anti-ASN.1, but it's actually remarkably similar to ASN.1's DER (distinguished encoding rules), which means it has lots of the same mistakes. It's all very sad.
[EDIT: I missed the second citation about why ASN.1 is inadequate. I will have to read that, though I'll admit that I am skeptical. Keep in mind that ASN.1 has been extended over time, so that one good question might be: what is missing that cannot be added? This is especially a good question when the alternative is to start from scratch.]
Note that I am [and my earlier comment certainly was] not defending or promoting ASN.1. I am saying that we have had a lot of reinventions of IDLs.
Now I'm also adding that a lot of ASN.1 haters don't really have a clue about ASN.1. Typically what they hate is a) the tag-length-value encoding rules (but not all ASN.1 encoding rules are TLV!), BER/DER/CER, and b) the syntax (which, whatever, it's just syntax).
The ASN.1 haters completely miss out on: the rather vast literature on encoding rules (including PER and OER which most closely resemble XDR), advanced features (e.g., the Information Object System), and especially the related SDL (which, granted, I believe simply hasn't had much use at all, at least that I'm aware of, but it's a very interesting idea that deserves more study). Instead, the ASN.1 haters generally produce or choose alternatives which either have roughly the same darned problems (Protocol Buffers, I'm looking at you), or a completely different set of also-obnoxious problems (e.g., JSON's escaping requirements for strings).
And so the circle of NIH [bad] wheel reinvention goes.
Another common objection to ASN.1 is lack of open source tooling. However, this is not really true anymore, with several decent open source ASN.1 compilers in existence. Of course, if you choose to invent a new IDL, then initially there will be no open source tooling for it!
I'm perfectly happy to not use ASN.1. I'll be perfectly happy if someone else doesn't use it. I'm not happy to see ASN.1 haters toss the baby (ASN.1's good ideas) out with the bathwater only to then reinvent the wheel badly. Your exceedingly-light on the evidence dismissal of ASN.1 is par for the course, and does not help.
EDIT: Note that I'm not calling you an "ASN.1 hater".
More importantly, there are NO conclusions in  (your ) that would support your dismissal of ASN.1. On the contrary, I would think it's the opposite. My conclusion is that you did not read your own references and did not do the research you should have done. This is, of course, par for the course in this sub-field of computer science. Everyone seems to always think they know better without actually making sure that they do. Some of this, of course, is due to the sheer cognitive load of the literature to which you and everyone else seem eager to add without doing anything to make it easier on the rest of us. You've taken the easy, lazy path. I'm not expecting you to do a full survey of IDLs, and I'm not expecting you to look at ASN.1 and say "aha! they have all the answers", but I am expecting you to have more than no idea about it when you reference it, or if you're going to use a reference as authoritative for some statement, make sure that it actually is.
If I've made a mistake chasing down references, please let me know. I'm eager to understand why you reject ASN.1. I'm particularly interested in what it is missing or does badly. Thanks.
I suppose I could have bought a Cadillac Escalade and spent a lot more on gas and maintenance while being able to haul a lot of people which would of never happened. It also would have cost quite a bit more than my Rio.
So, its not absurd to buy a Kia if it meets your needs instead of an Escalade, quite the opposite in fact. Just as it is really foolish to use CORBA when all you really need are the facilities already included with most Smalltalks. Just because I'm doing communications doesn't mean I need the big, expensive solution.
However, it's unfair to criticize CORBA for one of it's design tenets. It was designed for interop, hence the name.
Many solutions for transparent distribution were around the same time as Smalltalk. Look at systems like Eden, Emerald, etc.