API work

[roger peppe]

On 6 November 2013 13:59, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ...
>>
>> 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?
>>
>
> Given all the stuff that you describe that actually needs to be done,
> I don't quite see what we actually *gain* over just putting it into
> the RPC. We don't have to do auth again, we don't have to have the
> actual client connection suddenly switch from talking in one spot to
> talking in another, etc.
>
> I would be perfectly happy with PUT if we were already a RESTful API,
> but it seems a bit strange to just tack that on, and will be a
> one-more-special case that we run into when trying to debug, etc.
> (logs will likely be different, working in the code will have to think
> about multiple paths, etc.)

The reason is that if you've got a large charm (and we'll probably end up
uploading tools through this mechanism at some point) PUT streams
the bytes nicely, but we *really* don't want a single RPC containing the
entire charm as an arbitrarily large blob, so we'd have to add quite
a bit more mechanism to "stream" the data with RPC, and even then you
have to work out how big your data packets are, and you incur
round trip latency for as many packets as you send - this would
make charm upload quite a bit slower.

I suspect that the amount of work outlined above is actually quite a
bit less than
would need to be done to implement charm streaming uploads over the RPC
interface.