RE: P3P - Feedback on Access Control

Ian Hickson wrote:
> On Fri, 25 Jan 2008, Close, Tyler J. wrote:
> >
> > Well, imagine a SimpleDB-like service that didn't abuse GET
> in this way;
> > say it used the ATOM publishing protocol. In this case, each unit of
> > information has its own URI and is mutated using a non-GET
> operation.
>
> So each resource requires one additional round-trip. Unless you have a
> very unusual situation where you are manipulating a lot of
> resources only
> once, the cost is minimal.

Why is this situtation "very unusual"? It may be common. Say I've got a secure mashup application that manages an ATOM store. Since it's secure, the browser cache may be emptied after every visit, so the check requests will have to be repeated on each use.

> I do not believe that we should change the API to optimise for the one
> case of an API that involves a lot of non-GET requests to unique
> resources. It is trivial to optimise the server's protocol in
> this case
> anyway (just use one URI and put the parameters in the body), and this
> more closely matches what most people will be doing anyway.

It's my understanding that webarch tries to encourage the use of URIs, not discourage it. I believe the kind of protocol modification you suggest would be counter to what webarch tries to encourage:

http://www.w3.org/TR/webarch/#pr-use-uris

I certainly remember a lot of dissent from REST proponents about the way SOAP did just what you are suggesting.

> > Surely we don't want to encourage the abuse of GET to avoid this
> > performance penalty.
>
> Of course not. However, I don't believe the case you are describing is
> common. (I have no idea what evidence would convince you of
> this, so I'm
> not going to try to prove it.)

To date, you've offered no evidence and no argument to support your assumption. Surely you've got something you could offer.

> > The WG's current proposal also results in a tragically
> humourous network
> > protocol where the server tells the client to PUT to a URL
> and then the
> > client asks if it is allowed to PUT to that same URL, and
> repeats this
> > question for every URL it receives from the server.
>
> I would far rather have this situation than the situation
> where the client
> does a series of cross-domain PUTs that are unexpected.

Of course, it's not an either/or proposition. The server-side solution Mark and I have written about would not create these performance problems and negative design pressures. This argument is part of ISSUE-20:

http://www.w3.org/2005/06/tracker/waf/issues/20

--Tyler

Received on Friday, 25 January 2008 22:32:41 UTC