W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Last gasp terminology issue

From: David W. Morris <dwm@shell.portal.com>
Date: Wed, 5 Jun 1996 12:19:33 -0700 (PDT)
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.90.960605114520.5440A-100000@jobe.shell.portal.com>


On Wed, 5 Jun 1996 hallam@Etna.ai.mit.edu wrote:

> I think that this proposal attempts to go beyond the technical capability of 
> almost every server with a significant user base. Unless one is backing the 
> entire filestore as Jigsaw/CL-HTTP and like servers do it will not be possible 
> to perform the operation efficiently. Moving to a backing store architecture is 
> a major proposition and many operating systems simply could not support high 
> load with that architecture, it requires a single process - multithreaded 
> server.

I agree with Phill and Dan ... (others?)

Let me try and go back to basics to justify my conclusion.

With LastModified and IMS we are providing a protocol where by a provider 
can assure a customer that what they have is appropriate and applicable.
Given:
  1. The client doesn't change negotiable parameters in the headers otherwise
     an IMS isn't applicable
  2. The set of available variants does not change and their negotiable
     characteristics don't change.
Then the LMdate assigned by the server to the variant is sufficient. It is
not our problem to explain to servers that they must manage their 'database'
and if the variant should change, an IMS request will fail, and a new version
(and date) of the variant will be served.

If Given#2 fails, there are three cases:
1.  A variant is deleted:  The server selects the new best match and 
    serves it with appropriate modifications to the response to reflect
    the replacing variant. (Any caches SHOULD/MUST invalidate the requested
    variant)
2.  A new variant is created which would result in one or more previous
    variants being replaced as a result of the original negotiation 
    parameters
3.  Negotiation parameters associated with an existing variant changes
In cases 2&3, it is up to the server (the composite of software and people)
to make whatever filesystem/database status changes are required to
insure that IMS will fail for any existing variant which the server
wants considered for replacement because a possibly better negotiation 
match exists.

If LastModified (date and IMS) applies to the variant, then as I've described
above, the server has sufficient ability under the protocol to assure that
the client receives the appropriate version. We don't need to describe rules
about what LastModified means to a resource. How or what the server must
keep track of, etc.

Dave Morris
Received on Wednesday, 5 June 1996 12:24:41 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:02 EDT