Subject: IPP> transaction-based HTTP

From: Larry Masinter <[email-masked]>
Date: Fri, 31 Jan 1997 01:22:28 PST

HTTP/1.1 has both persistent connections and pipelining, so that you
can do several operations on the same connection without closing or
waiting for the return from one request before sending a second.

Persistent connections are optional; this is a good idea for a
small-memory server that wants to service multiple status requests.
(One job printing while multiple other clients are querying status).

Do any of the scenarios talk about the case of "50 simultaneous print
job attempts on a printer than can't buffer?". You'd probably like to
find out about capabilities and status (and even wait for availablity)
even from limited memory machines.

Larry

---

From: JK Martin <[email-masked]>
Date: Fri, 31 Jan 1997 10:39:54 -0500

> even from limited memory machines.

A more likely scenario is "100 simultaneous requests for printer and/or
job status".  If the world persists in assuming that the printer itself
is the place for every individual to seek the status of the printer,
then printer manufacturers will always have to worry about these kinds
of scaling issues.

This scenario is one of the primary motivations for the SENSE project,
along with reliable delivery of event information.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------