RE: PROPFIND instead of REPORT

I'll add one more vote for keeping REPORT around, Geoff, even without
Greg's argument around allprop (which I automatically discount).  Basically,
the question is whether or not PROPFIND should be a general RPC mechanism
for stuff not affecting server state (the non-destructive version of POST),
and I think that handling all the potential cases of missing arguments will
make PROPFIND reports very cumbersome and buggy where servers crash or fail
because the check for all the combinations of missing arguments missed
something.

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Greg Stein
> Sent: Tuesday, December 19, 2000 1:58 PM
> To: Geoffrey M. Clemm
> Cc: ietf-dav-versioning@w3.org
> Subject: Re: PROPFIND instead of REPORT
>
>
> And the first time some yin-yang does a PROPFIND/allprop to a
> resource, the
> server will get slammed as it computes every report. Of course, it will
> probalby just fail because it doesn't have the input parameters needed for
> some of the different reports.
>
> That is *very* bogus.
>
> Reports are NOT properties. Live or dead or whatever. They are a special
> request to the server to return a (possibly large) response about some
> aspect of the server, its config, or the data within the repository.
>
> Bad bad bad... please don't turn them into properties.
>
> Besides the allprop thing, how do you propose to marshal
> parameters for the
> report? By making them seem just like properties, this also takes away the
> notion of the "report-ness", so the available-reports thing now feels
> awfully arbitrary. But that is needed, because you can'd do a
> PROPFIND/propname and pick out what is a report and what isn't.
>
> Aesthetic? I think not. Some basic operations and semantics become quite
> twisted when you try to conflate the two.
>
> Properties don't have input paramters. Reports do. Don't mix them.
>
> -g
>
> On Tue, Dec 19, 2000 at 07:53:33AM -0500, Geoffrey M. Clemm wrote:
> >
> > OK, we've got 2 in favor of keeping REPORT (Tim, Greg) and 2 in
> > favor of using PROPFIND (Lisa, Tim).
> >
> > Last week I was in the PROPFIND camp, and due to the "DTD problem"
> > I switched to the REPORT camp.  I've convinced myself that there
> > really is no DTD problem, because a PROPFIND for a "foo-report"
> > could just be defined to return a "foo" in the response.
> >
> > So in fairness to the PROPFIND camp, I made a mental pass through the
> > protocol, to see what the effect would be to replace all "foo" reports
> > with a "foo-report" live property that returns a "foo" in the result.
> >
> > My impression was that this actually simplifies the protocol.
> > In addition, it would allow us to mark some of the current live
> > properties that really act as reports (i.e. DAV:successor-set,
> > DAV:baselined-collection-set, etc.) as being "reports" without
> > losing the benefits of being able to marshal them via PROPFIND.
> >
> > So I'd like to do the following: make an actual pass through the
> > protocol marshalling the current reports as properties, and post
> > the result for people to look at.  Since the arguments for keeping
> > REPORT appear to be mostly aesthetic, this would help us to
> > compare the two approaches (I'll keep the working draft with REPORT up
> > on our web site).
> >
> > Cheers,
> > Geoff
>
> --
> Greg Stein, http://www.lyra.org/
>
>

Received on Wednesday, 20 December 2000 13:38:45 UTC