Comments on: Batching – Back to Basics http://www.subbu.org/blog/2008/02/batching-back-to-basics Wed, 08 Feb 2012 05:16:45 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Subbu Allamaraju http://www.subbu.org/blog/2008/02/batching-back-to-basics/comment-page-1#comment-220 Subbu Allamaraju Wed, 27 Feb 2008 11:35:05 +0000 http://wp.subbu.org/2008/02/batching-back-to-basics/#comment-220 >> Ordering: Servers should be allowed to parallelize if they can prove the reordering doesn't affect the results. Typically this would be if they know the semantics of the operations (GET to a known resource) and so can easily execute in parallel. Other extensions could be added later to let a client provide parallelization hints; again, this would be a stumbling block if made a requirement for the basic batching protocol. I don't think an independent batching server can determine if reordering does not effect the results. It does not know if resources are somehow related in the backend (e.g. through some database). >> Ordering: Servers should be allowed to parallelize if they can prove the reordering doesn’t affect the results. Typically this would be if they know the semantics of the operations (GET to a known resource) and so can easily execute in parallel. Other extensions could be added later to let a client provide parallelization hints; again, this would be a stumbling block if made a requirement for the basic batching protocol.

I don’t think an independent batching server can determine if reordering does not effect the results. It does not know if resources are somehow related in the backend (e.g. through some database).

]]> By: subbu.org http://www.subbu.org/blog/2008/02/batching-back-to-basics/comment-page-1#comment-221 subbu.org Mon, 25 Feb 2008 13:56:49 +0000 http://wp.subbu.org/2008/02/batching-back-to-basics/#comment-221 <strong>Addressability of Fragments</strong> In his Addressing fragments in REST Simon St. Laurent says ...... Addressability of Fragments

In his Addressing fragments in REST Simon St. Laurent says ……

]]> By: John http://www.subbu.org/blog/2008/02/batching-back-to-basics/comment-page-1#comment-219 John Mon, 25 Feb 2008 11:43:48 +0000 http://wp.subbu.org/2008/02/batching-back-to-basics/#comment-219 Atomicity: This is an interesting and useful extension that could be requested/supported totally separately from batching. It's also something which is a stumbling block if made a _requirement_ for a batching protocol (as seen in the discussions of the Atom Working Group). Batching is useful without atomicity, so deploy it first, and add atomicity as an option later if it's useful. Ordering: Servers should be allowed to parallelize if they can prove the reordering doesn't affect the results. Typically this would be if they know the semantics of the operations (GET to a known resource) and so can easily execute in parallel. Other extensions could be added later to let a client provide parallelization hints; again, this would be a stumbling block if made a requirement for the basic batching protocol. Complexity: Yes, it's more complex, because it's an optimization. However, as proposed it's also completely optional, so it can be left out of a library or added in later without breaking clients. (Atomicity guarantees would for example make this impossible.) Atomicity: This is an interesting and useful extension that could be requested/supported totally separately from batching. It’s also something which is a stumbling block if made a _requirement_ for a batching protocol (as seen in the discussions of the Atom Working Group). Batching is useful without atomicity, so deploy it first, and add atomicity as an option later if it’s useful.

Ordering: Servers should be allowed to parallelize if they can prove the reordering doesn’t affect the results. Typically this would be if they know the semantics of the operations (GET to a known resource) and so can easily execute in parallel. Other extensions could be added later to let a client provide parallelization hints; again, this would be a stumbling block if made a requirement for the basic batching protocol.

Complexity: Yes, it’s more complex, because it’s an optimization. However, as proposed it’s also completely optional, so it can be left out of a library or added in later without breaking clients. (Atomicity guarantees would for example make this impossible.)

]]>