Re: Logic Bag concerns

There are times when it is easier to implement an abstraction that covers
a number of related problems than it is to implement each solution
one by one.  I realize that some folks have only seen the need for a
cache-validator, and therefore don't understand why I chose to design
a more general mechanism.  I am not surprised by that at all, and fully
expect people to question it (that is, after all, why we are all here).

On the other hand, it is a very new construct and I'm not going to throw
it away until everyone gets a chance to think about how it might be used,
and implementors get a chance to examine how it might be implemented on
their systems.  I also need to prepare three presentations for the next
two weeks of travelling, so I'd much rather talk about it at the Dallas
IETF and Boston WWW4 than try to defend it on a mailing list (there just
isn't enough bandwidth).

Here is the problem statement:

   How do you allow implementors to define a precondition on any method
   (not just GET) without requiring a change to the protocol version
   with every new precondition?

and the question is

   What is the actual difference in development and run-time expense
   between implementing a general mechanism for preconditions such as

       IF: {eq {Content-MD5 "89787jhlkr8r87y98437=="}}
   or
       IF: {eq {Last-Modified "Fri, 01 Dec 1995 14:13:06 GMT"}}

   over implementing a special-purpose mechanism for cache validation

       Content-Validator: "89787jhlkr8r87y98437=="
   and
       If-Validator: "89787jhlkr8r87y98437=="

   keeping in mind that no existing server currently provides a
   Content-Validator header field and that the field, whatever it
   contains, must be duplicating some other entity-header.

So, I weighed the issues, looked at the implementations, and decided that
the long-term benefits of a general-purpose solution was not only far
superior to the single-case, but was no more difficult to introduce to
the existing implementations.  In other words, I made a design choice.

Note that I use "IF" instead of "Unless" above -- I am not devoted to
either form -- just to the notion that we shouldn't need to change the
protocol every time someone thinks of a new precondition.

For example, let's consider payment.  Although many payment transactions
may be considered a complex interaction of exchanging offers and needs,
some are as simple as buying the morning paper.  What, then, if someone
in the future wants to state the condition

   GET this unless the price is more than I usually pay

Sounds reasonable to me (I do not claim to be an expert on payment
issues, by any stretch of the imagination).  To solve this person's
request, do we need to create a new protocol?  Or, do we allow those
people who are experts in the payment area define what "Cost" means,
how to compare two "Cost" values, and simply use

   GET this HTTP/1.1
   Unless: {gt {Cost "US$0.25"}}

This is the design tradeoff that I had in mind when I created the
Logic Bag syntax and the Unless (or IF, if you prefer) header field.

> validators and support for the first 2% of Common Lisp....and the rest
> can't be far behind :^].

Perhaps.  Dan Connolly forced me to look hard at the S-expression syntax
versus the ;parameter=value syntax, and I found the S-expressions to be
much better when the value could be a set, list, or structure.
I would not be surprised if the syntax, being simple and expressive,
turns out to be useful for things far beyond what can be anticipated
today.  At the least, I'll give it a couple months.

It should make for an interesting discussion on Monday.  See y'all
in Dallas.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Friday, 1 December 1995 19:01:59 UTC