API Bulk Operations

[John Arbash Meinel]

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

....

> For consideration: there are, I think, several cases (eg, all the
> ones we've mentioned so far) where there's only one sane per-entity
> error in a bulk Get. In that case a Result-with-Error is more
> heavyweight than we need: if we're getting, say, units, we could
> plausibly just return an []*Unit, with nil indicating NotFound. Any
> other error encountered in this context is, I think, a signal of a
> bulk-level problem (say the API server loses state conn half way
> through: that's analogous to an HTTP 500, and can kill the whole
> operation).
> 
> Not every case will follow this pattern, but I don't think we
> should be dogmatic about requiring result/error in every bulk-get
> result.

My problem is that if you are going to just put "nil" then *every*
client needs to zip over the request they sent and the response they
get so that they can figure out which items were found, and what was
omitted.

If you at least have Result, you can put they requested key in there,
and the error. Also, would you distinguish between "object doesn't
exist" and "you don't have access to that object"? That would already
be 2 types of errors.

> 
> 
> B. Covers most update operations: "do this on a bunch of things
> and tell me if each one was successful". Again, the returned errors
> match in order and count the passed id/params pairs.
> 
> 
> I think it's -> []error, error (in which individual errors are 
> differentiated from request-level errors). Sane?
> 
> 
> C. Covers a few operations, like AddMachine, AddUnit, 
> unit.AssignToMachine. Same semantics as for A.: Result contains
> both a potential error and any other fields as needed; error is not
> nil only when the bulk operation cannot be performed as a whole.
> 
> 
> I don't believe any of these cases are API-relevant. We never use
> the results, and anyone who's interested in them should/will be
> running appropriate watches. Right?
> 
> The Pinger case is a red herring because we shouldn't have exposed
> it in the first place ;p.

I actually was thinking to raise the question about Pinger as well,
but certainly that is a different thread.

...

> 
> I think the cost of making everything consistently bulk is
> negligible compared to the costs of having a mixture, and running
> the risk of getting it wrong sometimes. A bulk op will always work
> with a single element, but the converse does not hold.
> 
> Cheers William

I think this is a good way to look at it.

John
=:->

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

iEYEARECAAYFAlGnDjUACgkQJdeBCYSNAANaEQCdHVH4j+gATOB/AjJortFR1In/
scgAn350QcCYi6lbuaE7Ke3VJi3hb0Xa
=jhrE
-----END PGP SIGNATURE-----