W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: PROPFIND instead of REPORT

From: Greg Stein <gstein@lyra.org>
Date: Mon, 18 Dec 2000 06:59:17 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20001218065917.D30887@lyra.org>
On Mon, Dec 18, 2000 at 08:23:47AM -0500, Jim Amsden wrote:
> I agree that its a strech to think of these things as properties, but one 
> could consider Greg's example below to be the "synchronization properties" 
> of some root directory.

Now you're just being silly :-) You're trying to apply your PROPFIND hammer
to something that isn't a property. Sure... you can model *anything* as
properties, but that doesn't mean you *should*.

So yah... it's a stretch :-)

> My issue is that we already have a number of ways produce reports: using 
> servlets (or any other standard way of extending servers with custom 
> reports), POST, PROPFIND, and now REPORT. My first suggestion was to use 
> POST and just define the entity request body formats for interoperability.

POST is bogus for this. It is too overloaded and ill-defined as it is. It
also (typically) has semantics of "modify state on the server" while REPORT
is strictly non-modifying.

> This didn't seem appealing. Next came PROPFIND. I think POST and PROPFIND 
> are already existing, generic, extensible mechanisms while REPORT seems to 
> be sort of a special case method. There's no difference in the semantics, 
> just the marshalling, and POST and/or PROPFIND already provide sufficient 
> semantics.

PROPFIND is for fetching properties. REPORT is for fetching information
about the server, its layout/organization, for multiple disparate resources
and data, etc.

> Greg, your example below could be done without any extension to WebDAV as 
> your client can ask for the information it needs by doing PROPFINDs with 
> depth on a collection.

"could" being the operative word. Whether it "should" is a different matter.

Consider the case where the client has a working copy where all the
resources correspond to v7 from the repository. The repository is now at v9.
The client sends a report that contains something like:

REPORT /repos/my-project HTTP/1.1
...
<?xml version="1.0" encoding="utf-8"?>
<S:upgrade-report xmlns:S="...">
  <S:directory name="." version="7"/>
</S:upgrade-report>

The server then returns a report detailing all the new version resource
URLs, of all the resources in the repository, for the client to remember.
Some of those will also be marked as needing to be fetched because there is
a difference between v7 and v9. (note that most of the content won't change
between v7 and v9; just the version resource URLs)

The REPORT marshalling is *extremely* more efficient than crawling over the
repository doing PROPFINDs.

Cheers,
-g

> 
> 
> 
> 
> I find that using PROPFIND rather than REPORT is a big bogus. I'm not
> necessarily asking for properties. I'm asking for information from the
> server. Is a compare-report a set of *properties* ?? Not in my mind.
> 
> For Subversion, I'm also going to be using a custom report. The client 
> will
> send to the server a representation of the client state. The server will
> return a report saying something to the effect of, "that tree is out of
> date; that file is an older version, but is equivalent to the latest; 
> those
> files are fine; etc"
> 
> That isn't a PROPFIND :-)
> 
> Cheers,
> -g
> 
> On Mon, Dec 18, 2000 at 12:49:31AM -0500, Geoffrey M. Clemm wrote:
> >
> > At the recent IETF meeting, JimA proposed that we use PROPFIND instead
> > of REPORT to obtain information from the server that requires
> > arguments to qualify what kind of information is required.  Although
> > an appealing thought, after mulling this over, I don't see how we
> > could do this in a way that is compatible with PROPFIND but
> > does not violate the property value DTD's.
> >
> > Jim's recent post describing a request of this kind doesn't really work:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> >   <propfind xmlns="DAV:">
> >     <prop>
> >          <creator-displayname/>
> >               <versions>show-last-five</D:versions>
> >          <checkin-date/>
> >              <versions>show-last-five</D:versions>
> >     </prop>
> >   </propfind>
> >
> > If you indent this consistently, it becomes:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> >   <propfind xmlns="DAV:">
> >     <prop>
> >          <creator-displayname/>
> >          <versions>show-last-five</D:versions>
> >          <checkin-date/>
> >          <versions>show-last-five</D:versions>
> >     </prop>
> >   </propfind>
> >
> > which seems to be a request for creator-displayname, checkin-date, and
> > a repeated request for a property named "D:versions" (I'm assuming
> > that all elements should have been prefixed by "D:").
> >
> > Based on his original indentation, JimA probably meant:
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> >   <D:propfind xmlns="DAV:">
> >     <D:prop>
> >          <D:creator-displayname>
> >            <D:versions>show-last-five</D:versions>
> >          </D:creator-displayname>
> >          <D:checkin-date>
> >            <D:versions>show-last-five</D:versions>
> >          </D:checkin-date>
> >     </D:prop>
> >   </D:propfind>
> >
> > But now we've violated the DTD's for D:checkin-date and
> > D:creator-displayname (which are supposed to be either empty or
> > dates and strings, respectively, to display to the user).
> >
> > Currently, I think the avoidance of DTD ambiguity is worth
> > the introduction of a new method (i.e. REPORT).
> >
> > Cheers,
> > Geoff
> >
> >    From: "Lisa Dusseault" <lisa@xythos.com>
> >    Date: Sun, 17 Dec 2000 16:33:44 -0800
> >
> >    I'm afraid I'm a little confused, perhaps it's just the indenting. Is
> >    the <versions> tag supposed to be inside each the property name tags, 
> or
> >    parallel to them?
> >
> >    I'd suggest one only needs one <versions> tag per PROPFIND body, 
> because
> >    it's pretty nonsensical to ask for one property over 5 versions, and 
> a
> >    different property over 50 versions, all in one request. the client 
> is
> >    more likely to make separate requests.
> >
> >    Another suggestion is to reuse the "range" syntax and logic (e.g.
> >    byte-range headers).  This allows a "last-n" selection, as well as "m
> >    through n" or "first n".  Then we don't need to define custom syntax 
> or
> >    logic to pick which versions to show.
> >
> >    The basic idea, I think, is sound.
> >
> >    lisa
> >
> >    -----Original Message-----
> >    From: ietf-dav-versioning-request@w3.org
> >    [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Amsden
> >    Sent: Sunday, December 17, 2000 7:26 AM
> >    To: ietf-dav-versioning@w3.org
> >    Subject: RE: Minutes Delta-V breakout meeting 14-Dec-00
> >
> >
> >    <lisa>
> >    Hmm, this really argues for using PROPFIND since the client can say 
> what
> >    props they want for the version.  Perhaps instead of using attributes 
> in
> >    the
> >    body of PROPFIND request (I never really understood where they would 
> go)
> >    there could just be an XML element to tell the server whether the 
> client
> >    wanted version detail or not:
> >
> >    PROPFIND thisresource
> >
> >    <?xml version="1.0" encoding="utf-8" ?>
> >      <propfind xmlns="DAV:">
> >        <versions>show-last-five</D:versions>
> >        <prop>
> >           <creator-displayname/>
> >           <checkin-date/>
> >        </prop>
> >      </propfind>
> >    </lisa>
> >    <jra>Lisa, here's what we were planning:
> >
> >    <?xml version="1.0" encoding="utf-8" ?>
> >      <propfind xmlns="DAV:">
> >        <prop>
> >           <creator-displayname/>
> >                <versions>show-last-five</D:versions>
> >           <checkin-date/>
> >               <versions>show-last-five</D:versions>
> >        </prop>
> >      </propfind>
> >
> >    This is more compatible with 2518.
> >
> 
> --
> Greg Stein, http://www.lyra.org/
> 
> 

-- 
Greg Stein, http://www.lyra.org/
Received on Monday, 18 December 2000 09:55:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT