Re: Schema for Juju RPC messages

On 28 July 2016 at 15:11, Mark Shuttleworth wrote: > 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

Re: Schema for Juju RPC messages

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

Re: Schema for Juju RPC messages

On 28 July 2016 at 12:12, Mark Shuttleworth wrote: > On 28/07/16 12:57, roger peppe wrote: >> On 28 July 2016 at 10:01, Mark Shuttleworth wrote: >>> On 28/07/16 10:42, roger peppe wrote: On 28 July 2016 at 01:07, Rick Harding

Re: Schema for Juju RPC messages

On 28/07/16 12:57, roger peppe wrote: > On 28 July 2016 at 10:01, Mark Shuttleworth wrote: >> On 28/07/16 10:42, roger peppe wrote: >>> On 28 July 2016 at 01:07, Rick Harding wrote: However, an API client in any language should never be auto

Re: Schema for Juju RPC messages

On 28 July 2016 at 10:33, John Meinel wrote: > ... >> >> >> FWIW there is a proposal for strict field checking in the Go >> encoding/json package (https://github.com/golang/go/issues/15314) >> which would fix the specific issue raised at the start of this thread. >> It's

Re: Schema for Juju RPC messages

... > I actually think that local charm upload is different enough that it > justifies a separate entry point. I agree that AddCharmWithAuthorization > should be folded into AddCharm though. > FWIW, I'm pretty sure we have 2 APIs because someone didn't want to bump the API version to add some

Re: Schema for Juju RPC messages

... > > FWIW there is a proposal for strict field checking in the Go > encoding/json package (https://github.com/golang/go/issues/15314) > which would fix the specific issue raised at the start of this thread. > It's trivial to add that feature (4 lines of code) and pending Go 1.8, > we could

Re: Schema for Juju RPC messages

On 28 July 2016 at 01:25, Rick Harding wrote: > My understanding is that we need three distinct calls in the API because of > Go and the way that these things need to be declared/defined. Actually, it would be perfectly possible in Go for there to be only a single

Re: Schema for Juju RPC messages

On 28/07/16 10:42, roger peppe wrote: > On 28 July 2016 at 01:07, Rick Harding wrote: >> However, an API client in any language should never be auto generated. > This is a strong statement. I feel that, as with most things in > software engineering, > there's a

Re: Schema for Juju RPC messages

On 28 July 2016 at 01:07, Rick Harding wrote: > However, an API client in any language should never be auto generated. This is a strong statement. I feel that, as with most things in software engineering, there's a trade-off. Personally I'm with Katherine "use the

Re: Schema for Juju RPC messages

On 28/07/16 05:30, Tim Penhey wrote: > Just doing this would catch the typos of keys, and would also make us > be more strict in the "I'll just add this extra field" to existing > facade versions, as they could then fail with older versions of the > server with "unknown field" type errors.

Re: Schema for Juju RPC messages

On Wed, Jul 27, 2016 at 8:25 PM Rick Harding wrote: > That being said, any API client that requires three API calls to login >> should be beat over the head with a fail stick, but there are many cases >> where performing some workflow might require multiple api calls.

Re: Schema for Juju RPC messages

While at the London sprint I was toying with the idea of adding the ability of the rpc package to do some rudimentary initial validation. We could get a good part of the way with relatively little effort IMO. Using the reflect package, we can interrogate the public attributes of the structure

Re: Schema for Juju RPC messages

> > That being said, any API client that requires three API calls to login > should be beat over the head with a fail stick, but there are many cases > where performing some workflow might require multiple api calls. The API > clients should work out a single function of

Re: Schema for Juju RPC messages

On Wed, Jul 27, 2016 at 3:18 PM Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > Good point, Mark. I agree that it's difficult to make an auto-generated > client idiomatic/nice to use. What I like to do is use the schema to > auto-generate the boilerplate, and then wrap that with

Re: Schema for Juju RPC messages

Mark Shuttleworth writes: > On 27/07/16 19:43, Reed O'Brien wrote: > > +1 > > > On Wed, Jul 27, 2016 at 9:52 AM, Katherine Cox-Buday > wrote: > > > I am a huge fan of publishing schema's and then

Re: Schema for Juju RPC messages

On 27/07/16 19:43, Reed O'Brien wrote: > +1 > > On Wed, Jul 27, 2016 at 9:52 AM, Katherine Cox-Buday > > wrote: > > > I am a huge fan of publishing schema's and then generating SDKs > and documentation websites

Re: Schema for Juju RPC messages

+1 On Wed, Jul 27, 2016 at 9:52 AM, Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > > I am a huge fan of publishing schema's and then generating SDKs and > documentation websites off of them. It brings your API closer to language > agnostic, removes the burden on us having to

Re: Schema for Juju RPC messages

I am a huge fan of publishing schema's and then generating SDKs and documentation websites off of them. It brings your API closer to language agnostic, removes the burden on us having to hand-craft both our API client and our documentation site, and makes validation implicit. I'm not up on

Schema for Juju RPC messages

We've had some requests from people trying to drive Juju that it would actually be really nice if we were stricter with the messages that we accept on our API. Specifically, as we've changed the API methods, they had several hard-to-debug problems because they were passing a parameter that was