RE: again: OPTIONS semantics

RE: again: OPTIONS semanticsOK,

let's take that further -- this is a real implementation issue, not just
academic.

I have *one* servlet "/a" that controls access to different backends through
different namespace partitions such as "/a/filesystem", "/a/jdbc" and so
on... One backend may support workspaces, the other won't.

Would you still consider this "multiple" servers?
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

  -----Original Message-----
  From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
  Sent: Thursday, September 26, 2002 11:22 PM
  To: ietf-dav-versioning@w3.org
  Subject: RE: again: OPTIONS semantics


  I would classify two different servlets as two different
  servers, and so if the servlet handling the OPTIONS request
  does not know about the update feature, then it is expected
  to not return "update" in the DAV header.

  Cheers,
  Geoff

  -----Original Message-----
  From: Julian Reschke [mailto:julian.reschke@gmx.de]
  Sent: Thursday, September 26, 2002 5:16 PM
  To: ietf-dav-versioning@w3.org
  Subject: again: OPTIONS semantics




  Just taking an example from section 7:

  "Additional OPTIONS Semantics
  If the server supports the update feature, it MUST include "update" as a
  field in the DAV response header from an OPTIONS request on any resource
  that supports any versioning properties, reports, or methods."



  So assuming my DAV namespace is separated into two parts (for instance by
  servlet) "/a" and "/b". Both parts of the server namespace support
  versioning, but only "/a" supports workspaces. Should the "update" feature
  be reported on "/b" and it's descendants?

  The spec says "yes", but I don't think this is implementable (for
instance,
  the servlet responsible for "/b" may not even know about the existence of
  "/a").

  Julian

  --
  <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760