API work

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...

>> 
>> 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.
> 

The chunked implementation in golang just uses io.Copy which reads and
writes everything in 32kB chunks. We could just as easily do the same
thing, or just make them 1MB chunks or whatever. We can just as easily
pipeline the RPC requests which is what is being done with
transfer-encoding: chunked.

I think your statement about "how big your data packets are" etc is
making it more complex than exists in reality. It would be nice if
things did that, but they clearly don't.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ6UlsACgkQJdeBCYSNAAPgDwCgqjvid7hAv/IFpl1rgLgUHYAz
mkYAn0wgh/2S/Yp33pFKIG8Rzf0YbPPH
=gcI1
-----END PGP SIGNATURE-----