On 6 November 2013 13:30, William Reade <[email protected]> wrote: > On Wed, Nov 6, 2013 at 1:49 PM, roger peppe <[email protected]> wrote: >> >> FWIW I'm strongly in favour of *not* sending charms through >> the RPC interface - it is likely not incur a significant performance >> hit over a high latency connection. I don't *think* that implementing >> a PUT handler on the API server should be too much of a problem. > > > I'd like to see a slightly more detailed plan here, but I'm not against that > in principle.
So, we discussed some of this in SFO. The only wrinkle is that currently the websocket-based is available on every path of the exported HTTP interface (that is, connecting to wss://my.juju.server/lkdjnsvfdv will give you the API just as well as wss://my.juju.server/. Long term, I'd like to deprecate the root as a way of talking to the API and mandate (for instance) /api as a URL path. Short term, we can't do that, but we *can* treat, for instance /charm differently and serve PUT (and potentially GET requests) on that. It's just a matter of adding a ServeMux in apiserver.Server.run. The other issue we'd need to deal with is authentication. I'd suggest we would specify that the URL parameters should include the user name and password. If we didn't want to do that, there are alternatives which I won't go into here as they're more complex. So to summarise, the URL might look something like: https://my.api.server/charm?user=admin&password=adminpassword&charmurl=cs:precise/wordpress We'd do a PUT request on the above URL, sending the charm bundle. We may well want to add a secure hash of the charm bundle too, so that we can tell if the user accidentally drops the connection too early. I don't think that charms are generally big enough to warrant adding resumable uploads, at this point anyway. How does that sound? -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
