RE: [ACL] REPORT vs SEARCH

Julian Reschke writes:
> due to the recent discussion on the ACL list, I have done a comparison of
> PROPFIND, (ACL/deltaV) REPORT and (DASL) SEARCH. My conclusions are:
>
> - There are three methods with partly overlapping features: PROPFIND
> (defined in RFC2518), REPORT (defined in the soon-to-appear
> deltaV RFC) and SEARCH (expired draft).
> REPORT and SEARCH seem to be almost identical in features -- both just
> define frameworks into which query/report grammars can be plugged in.
> - There doesn't seem to be anything in the DASL framework that couldn't be
> done with REPORT. In fact, query grammar (REPORT) discovery seems
> to have a more elegant solution.

My view on the distinction between the three methods (PROPFIND, SEARCH,
REPORT) is as follows:

* PROPFIND is useful when the client knows exactly which properties, on
which resources, it wants to retrieve. It is also useful for discovering
what properties are defined on a resource.

* SEARCH is useful when the client knows what property values it wishes to
retrieve, but it cannot compute ahead of time the set of resources for which
it wants those property values. While the client could just retrieve the
properties from all resources, and then perform a comparison in-memory, this
is *extremely* inefficient from a network resources standpoint. SEARCH can
perform an unconstrained number of different kinds of searches on the
server, and so it is very difficult for the server to optimize specific,
frequently-occurring searches.

* REPORT is useful when the protocol designers can predict that a specific
search will be very useful, and will occur frequently. This allows a server
to optimize the performance of these queries. Additionally, REPORT allows
complex search semantics to be defined that might not be expressable using
SEARCH. But, REPORT was never desgined to accommodate a wide range of fairly
unconstrained queries (such as those expressable using SQL).

In my view, each of these methods has its niche, and each has value.  As a
result, I favor:

a) continued development on the DASL specification. Lisa Dusseault has
volunteered to edit this specification, and I'm expecting a new draft from
her in the near future.

b) the addition of specialized REPORTs into protocol specifications, as
needed.

> Proposal: drop work on DASL.

I think this is a bad idea.  A general purpose search mechanism is necessary
to unlock the value of properties.

 Instead define an (extensible) equivalent of
> DAV:basicseach, with the following additional features:
>
> - discovery of searchable properties
> - discovery of supported constructs in the grammar
> - better signaling of execution errors (non-searchable properties, not
> recognized grammar constructs)
> - definition of a mandatory subset of query grammar features
>
> Publish this as separate RFC, or possibly move it into RFC2518++.

These look like a useful set of requirements for DASL.

- Jim

Received on Friday, 5 October 2001 13:29:16 UTC