Schema for Juju RPC messages

[Mark Shuttleworth]

On 28/07/16 13:47, roger peppe wrote:
> I agree with that. But we're talking about sugar here, I think. Added
> sugar doesn't *necessarily* imply a cleaner, less messy or better
> articulated component IMHO. That's one of the reasons I like Go - more
> layers of abstraction can make things harder to reason about, although
> equally they can sometimes really help. 

We're not talking about sugar.

Look at your example - it got *shorter* when hand crafted. That's *less*
fluff.

We all value different things individually, and I respect the things
that you in particular value. However, we can also make concrete
observations about the behavior of humans at scale. And we know that
developers respond really well to clear documentation, clear and
interesting demos, and elegant APIs in the language of that choice.
You're saying we could save a small amount of time by writing code, I
say that we pay that small price at the time and then your audience -
the developers - benefits every time they look at your work. As a team,
we can both value your values, and set a goal to shoot for what we know
works with the developers who are our audience.

I don't ask the Juju core team to maintain charms or visit customers to
work on charms. Your audience is developers who will integrate, and I do
expect us as a team to be mindful of that and set a very high bar.
Auto-generated code has been the same clever idea since the 1980s and it
has always produced the same result - a brief high matched with ultimate
frustration and distaste.

> In this world of limited development time, all else being equal, I
> tend to prefer "no code at all" over a "bounded amount of code",
> because all code implies potential bugs and ongoing maintenance
> cost. Is that being too much of a lazy programmer? Quite possibly.
> Where to draw the line between pragmatism and perfection is
> something that's always on my mind, something that we're
> all exploring all the time.

That's good. As a team, however, on this codebase, we have a commitment
to a particular approach. That way, it doesn't feel like a hodge-podge
of explorations.

Katherine, thanks for opening the subject. We are agreed that
schema-based internal validation of messages and calls, on both the
client and the server, offer long-term value and we should do them, with
an initial approach that is cheap and also relatively effective. Our
bindings, however, will be handcrafted, and we will critique them for
taste. I suggest we designate people to act as leads for the different
languages we target (Go, Python, JS) with the goal of having those folks
lead consistency (but each committer is responsible for updating the all
bindings of the APIs they touch).

Mark