Re: mod_dav_svn backward compatibility broken?

On Tue, Mar 04, 2003 at 03:16:01PM -0500, mark benedetto king wrote:
>...
> 1.) A custom request header
>...
> 2.) A capabilities header
>...
> 3.) A custom *response* header

These are all way, way bogus. Non-starters.

>...
> 4.) Use existing properties infrastructure.

I'm unclear on what this means, but am skipping anyways.

>...
> 5.) Do nothing.

Doesn't work in the long run.

>...
> 6.) Do less than nothing (stop validating S:prop so thoroughly) (be
> liberal in what we accept).

The only valid answer.

We have to be able to deal with new elements suddenly appearing at any place
in the XML response. Otherwise, we'll never get any kind of interoperability
moving forward. If the server starts stuffing new items in, then the client
should just ignore them. If the client expects something, but the server
doesn't provide it, then the client should gracefully degrade (or signal
that it requires the new data from the server, and cleanly abort the
operation).

There are several things that we can do:

  1) stop returning NE_XML_DECLINE. return NE_XML_VALID and jettison the
     unknown element in our start_handler. (this shifts the "ignore unknown
     elements" from the validator to the element handler)

  2) stop using Neon's XML parsing. we have Expat, so this might not be too
     hard, but is certainly more work than (1).

  3) beat Joe into adding NE_XML_IGNORE for elements which are "valid" but
     can simply be ignored [if no other handler wants them]. we would then
     need a mandated upgrade of Neon.

My favorite is option (1) for short term (the 0.19 release), and option (3)
for the long term plan.

In all cases, this also implies that the server should stop sending the UUID
for now, until we get "enough" clients with the flexible handling. If we
really need the server to send the UUID, then we can *temporarily* put the
thing into the server headers; that works fine for ra_dav, but is not a good
long-term WebDAV-y solution.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org