Re: PaceBatch and pipelining

[Mark Baker <distobj@xxxxxxx>]

Sorry I haven't had time to keep up with this thread, but thanks to
Roy for stepping up.

On Tue, Jun 28, 2005 at 10:11:36AM +0200, fmantek wrote:
> > Just to put this in context...  by virtue of APP being HTTP/1.1 based,
> > it already has a batching mechanism; HTTP pipelining.  PaceBatch would
> > be a second batching mechanism.
> 
> I think there is a big difference between HTTP pipelining and
> batching. From my understanding, and please correct me, as this is
> very basic:

Without responding to those points individually, because I think I have
already in other messages, I'd just observe that while the concept of
batching (as you describe it) may be more generic than HTTP pipelining,
PaceBatch, as designed, is a pipeline solution (a tunneled one in fact,
of HTTP over HTTP).  Another design is alluded to in the Pace notes, and
as I said, I could probably be convinced to support that if HTTP
pipelining doesn't meet the requirements.

What such a design might look like, would be to have a separate resource
related to the collection by a defined relationship, to which, for
example, multiple entries can be POSTed.  Here's a new introspection
document which would declare this new resource and relationship;

   <?xml version="1.0" encoding='utf-8'?>
   <service xmlns="http://purl.org/atom/app#";>
     <workspace title="Main Site" >
       <collection contents="entries" title="My Blog Entries"
         href="http://example.org/reilly/feed";>
         <batch href="http://example.org/reilly/feed/batch"; />
       </collection>
     </workspace>
   </service>

This would permit, say, a multipart envelope containing individual
entries to be POSTed to the "batch" URI and have that interpreted as a
request to POST multiple individual entries.  The separate resource is
required to distinguish the action of POSTing of a single multipart
entry, from the action of POSTing of multiple individual entries in a
single package (i.e. a multipart entry).

Would something like this meet your requirements?  Again though, it
would be better if HTTP pipelining was "good enough" for you, since
that comes For Free.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.          http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com