Inter-Server Performance is Important

[Tom Snyder]

With today's fast computers, users are used to snappy performance from
their apps.

Each folder browse or file save via OpenSAM WebDAV might require 1-6
requests to the WebDAV server to implement - PROPFIND, PROPPATCH, PUT,
etc.

We strongly recommend Home applications (that do the WebDAV serving)
be engineered to statisfy most requests in less that 500 ms each. The
best Home applications will regularly satisfy requests in less that
250 ms.

Good Productivity applications will cache the results of prior
requests (PROPFIND) and not repeat the same requests during the
performance of a single task. The best Prodcuctivity applications will
use keep-alive connections throughout a single task to optimize their
connectivity to the Home application.

Should we make any of this a "MUST" to be fully OpenSAM?

[Anton Bar (G.ho.st)]

It's a very good point.

I think it should be "RECOMMENDED" according to http://tools.ietf.org/html/rfc2119.

[Zvi Schreiber (G.ho.st)]

What do we do when there is a big folder contents which might take a
while to transmit. Our preference is to send it a "page" at a time
and show it to the user paginated - this seems to be the standard
approach for web apps - but I'm not sure WebDAV supports it - does
it? If not it's one of the areas we would like to extend WebDAV -
other areas being search and maybe sharing.

Zvi

[Anton Bar (G.ho.st)]

I think that paging is very important for web based storage systems.

If there is a possibility to extend WebDAV, then I think that we need
the "chunked" or "buffered" operations also with files. For example:
- Go to byte #10000 (like seekg)
- Read 15K of data

It'd be great also to run X-Path queries on XML files. For example:

- GET /files/contacts.xml/users[name="anton"]
returning something like <user name="anton><address>...</
address><phone1>...</phone1>...</user>

or

- POST /files/contacts.xml/users[name="anton"]
phone1=5551234

[Adam Rosien]

Adding gzip/compress support to providers and clients will help a lot
in this regard outside of any query and paging mechanisms. This
*should* be as simple as flipping a switch in your web server.

.. Adam

[Tom Snyder]

HTTP 1.1, and therefore WebDAV, currently support getting portions of
a result via the Range: request header and Content-Range: response
header. Most commercial WebDAV servers support these Range: specified
requests. Therefore it is up to the client -- an OpenSAM productivity
app -- to include the Range: header in their request and paginate the
response for the user.

I personally doubt whether the size of folder listings will grow that
large, but it does help to handle even extreme cases. With the OpenSAM
servers being connected on the Inet backbone, requests of 50-500 KB
should still be blazingly fast. We've tested iNetWord on folders
containing 100s of files with no apparent slowdown.

The use of the Range HTTP header is another good example why WebDAV is
the right choice for us -- we inherit all the work and support already
invested in solving these problems for HTTP and WebDAV.