Subject: Re: Precepts of Goland

From: Jim Davis <[email-masked]>
Date: Tue, 04 Jan 2000 14:16:48 +0100

At 11:50 AM 1/3/00 -0800, Yaron Goland wrote:
>...Let us first see if we can establish agreement on some very basic
>precepts. I will start with just one precept and see if we can get agreement
>on just that...

This is a good strategy to clarify the issues.

But there are two things I am unclear on.

First is procedural.  RFC 2518 exists, and has a fixed and known set of
authors.  When we have discussions like this, is the underlying assumption
that the conceptual model of RFC 2518 was either unclear, internally
inconsistent, or mistaken (perhaps because it can't be extended to support
new ideas like BIND?)  another way to say this, are we trying to
retroactively induce a consistent conceptual model for something that
already exists, or design something for the future.

Second concerns Precept #1

>
>Precept #1 - HTTP clients send HTTP request messages to resources that
>respond with HTTP response messages.

This seems reasonable, but there is at least one alternative.

Precept #1a - An HTTP client sends an HTTP request message  to a server
(which is a process running on a specific host at a specific port).  The
server interprets the URL in the request.  If the URL identifies a
resource, the server relays the method to the resource.  If not, server
interprets the method. For some methods, a 404 is issued.  For others,
something else happens.  What that something else is depends, on a case by
case basis.

This precept is more complicated, but does not require the ficticious "null
resource" neeed in Corollary #1.3  

>Corollary #1.3 - Since HTTP request messages can only be handled by
>resources which respond with HTTP response messages then even error messages
>such as "Not Found" must have been generated by a resource.

I have no position on whether 1a should be prefered to 1, nor do I claim
that this is the only other alternative to #1.

---

From: Yaron Goland <[email-masked]>
Date: Tue, 4 Jan 2000 09:48:27 -0800

> already exists, or design something for the future.

My own goal would be to establish what the object model for DAV SHOULD be.
If that requires us to violate RFC 2518, so be it. That is why it is called
a Proposed Standard. That means it can and will change. But, BTW, we should
not be to ready to change RFC 2518. If we do we will be required, if not by
IETF process then by common sense/market pressures, to make changes in such
a way that RFC 2518 clients/servers can continue to operate correctly.

> resource" neeed in Corollary #1.3  

What is the difference between throwing in a new object, called a server,
and describing an instance of a resource called the null resource? They are,
point for point, the exact same idea. The big difference is that a null
resource allows us to leverage an object model with a single object and
describe behaviors with it. Talking about the server throws us into a lot of
really awful questions about how an implementation is put together. What
happens when a proxy is involved? What happens when I have a server farm?
What about a three tier system? I generally prefer to opt for the cleanest
abstraction, I believe that declaring there is one and only one object - a
resource and then basing everything off that single object will be the
cleanest way to go. Therefore I strongly prefer Precept #1.

		Yaron

---

From: Jim Davis <[email-masked]>
Date: Tue, 04 Jan 2000 23:28:35 +0100

At 09:48 AM 1/4/00 -0800, Yaron Goland wrote:
>So Spoke Jim Davis:
>
>> Precept #1a - An HTTP client sends an HTTP request message  
>> to a server...
>> 
>
>and describing an instance of a resource called the null resource? 

Well, this is just my intuition speaking, but I think many people are
comfortable with the idea of a "web server" being some chunk of software
that listens on a port, accepts HTTP requests, and interprets them somehow.
 It's a relatively familiar notion.  Surely if I talk about "the Apache Web
server" or Microsoft's IIS, people know roughly what I mean.  I am less
sure that people have an intuition about a null resource, especially since
we seem to need both a "plain" null resource and a "locked null" resource.
but again, this is just a hunch.

Even if I am right, it could also be that that very familiarity makes it
treacherous -- because t might be carrying conceptual baggage that does not
belong, e.g. people might start expecting WebDAV to provide a live property
that contains recent log entries or something.

Rather than debate this point any further, I will be silent a while and see
if anyone else has anything more principled to offer than a bare intuition.
 Or perhaps there is yet another Initial Precept.

regards

Jim

---

From: Jim Davis <[email-masked]>
Date: Tue, 04 Jan 2000 23:21:06 +0100

At 09:48 AM 1/4/00 -0800, Yaron Goland wrote:
>>... are we trying to
>> already exists, or design something for the future?
>> 
>not be too ready to change RFC 2518. If we do we will be required, if not by

Great, that's just how I see it too.  So on with the precepts then.