Schema for Juju RPC messages

roger peppe roger.peppe at canonical.com
Thu Jul 28 09:14:20 UTC 2016


On 28 July 2016 at 01:25, Rick Harding <rick.harding at canonical.com> 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
AddCharm. It's a matter of taste, I think. The Juju Go API is not
auto-generated.
Someone has made a specific decision to use three different calls there,
rather than (say) a call like:

    // AddCharm adds a charm to the model. It returns the URL assigned
    // to the charm, which will be the same as p.URL except when uploading
    // a local charm.
    func (c *Client) AddCharm(p AddCharmParams) (*charm.URL, error)

    type AddCharmParams {
        // URL specifies the URL of the charm, which must include the revision
        // unless a local charm is being uploaded.
        URL *charm.URL
        // Channel specifies the channel from which to retrieve the charm.
        // This must not be specified when uploading a local charm.
        Channel csparams.Channel
        // If Charm is specified, it holds a local charm to be uploaded.
        Charm charm.Charm
        // Auth holds authorization for retrieving the charm from the
charm store.
        // This must not be specified when uploading a local charm.
        Auth *macaroon.Macaroon
    }

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.

> However, pushing that down into API clients is pushing implementation details (Go in
> this case) down into clients in other languages where this would not be so
> required.

I don't believe that it's Go forcing the issue here - there's no
particular reason
AFAICS why using Go means that AddCharm should be a separate RPC call
from AddCharmWithAuthorization, for example.

In the end, the network API has a certain number of entry points and clients
are going to need to talk to them. When possible, having automatically
generated low
level code that has a one-to-one correspondence with those ("auto-generated
validation") seems like a useful thing to me.

  cheers,
    rog.



More information about the Juju-dev mailing list