RE: New PEP draft available as ID!

At 03:18 PM 4/30/97 -0700, Yaron Goland wrote:
>I was just sitting down to read through the 23 or so pages of the PEP
>draft when I asked myself "Why?" My original interest in PEP was caused
>by my work in DAV where I needed to extend HTTP in all sorts of
>interesting ways without breaking anything. In the end however, I
>discovered the whole effort was largely for not because PEP only works
>if everyone supports it and currently, no one supports it. This would be
>the famous chicken and egg problem.

But you also have to ask yourself the question HOW you want to extend your
implementation. DAV is not the only extension to HTTP being worked - and
will not be the last either.

Having used a lot of time on writing HTTP implementations myself, I would
certainly not want to change the core HTTP engine every time I implement a
new extension. PEP is a wire protocol - not an API but it makes it easy to
code extensions as separate modules and maintain a nice interface to the
rest of the application.

At the IETF meeting in Memphis, the message about complexity was very
clear. We have been thinking a great deal about how to make PEP simple -
really simple - to make it worth doing even for small extensions. Eric
Prud'hommeaux is currently working on a sample implementation of PEP in
Java which will prove our point.

>However I did spend some time thinking about what the world would look
>like if PEP did exist and the answer is "expensive". Having to send
>along a bag with all those options, not to mention writing all the
>supporting code, just seems like maximum overkill. The solution we are
>using in DAV is to have clients look up a particular attribute to see if
>a set of features are supported. Once you have attributes, PEP becomes
>largely irrelevant.

What exactly is it in the latest draft that you consider to be expensive?
The new model described in this draft consists of two parts:

1) The client introduces new extensions using the PEP header saying: "These
are the headers, I am gonna use and this is what they mean".

2) The server can ask the client to use an extension by using the 420
status code and say which extensions using the PEP-Info header.

Depending on the extension and the server, this can be done once and you
may for ever after use the extension simply by using the headers. The
reason why PEP may seem powerful is that you can do almost anything using
this model but it is still simple.

>I realize that PEP is a lot more powerful than a simple "check the
>switch" solution but in all the real world scenarios I am looking at,
>such as deploying DAV, I don't seem to need anything more than the
>attribute. Has someone else had a different experience?

PS: I would much prefer to have more concrete feedback on the technical
aspects of PEP instead of discussions about lines of code. All I can say is
that the current PEP draft _is_ simple to code and we are working on
proving it with running code.

PPS: Sorry for not supplying diffs or change bars from previous versions.
The reason is that most of the document has changed due to many stylistic
and technical changes and so change bars didn't make sense.

Thanks!

Henrik

--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA

Received on Thursday, 1 May 1997 09:28:53 UTC