On Thu, Jun 20, 2002 at 09:25:43AM -0500, brane@tigris.org wrote:
>...
> Log:
> There was some discussion on IRC a couple of days ago about how it
> would be nice if mod_dav_svn could produce directory indexes in XML
> instead of HTML. So, finding myself with some spare time, I played
> around a bit.
>
> * mod_dav_svn.c (dav_svn_cmds): Recognize option SVNIndexXSLT. If it's
> defined, dir indexes will be generated in XML. The default is HTML.
I've said this before, and I'll reiterate it again:
mod_dav_svn should NOT have options to configure its output. This is a
*HUGE* slippery slope. There are way too many possibilities for output.
"Well, I want it tweaked like this." "And I want this feature." Before you
know it, we have a dozen options to configure this stuff, and pages and
pages of code. The builtin collection response exists solely to provide
*some* utility. If you want more, then it belongs *outside* of
mod_dav_svn. Put it into a filter, another module, or a CGI script. Don't
bulk up the C code.
Just look at this stuff. We already have another command to set a
repository name. Where does it end? Two of mod_dav_svn's four directives
are solely to support one small aspect of its functionality.
To some extent, this commit pisses me off. Then again, I also recognize that
an XML output option can be very handy. So maybe something along these lines
would be good.
However, the design of this has severe shortcomings. If somebody configures
their site for the XML output, then people will downlevel browsers can't
read the page at all. So what this change does is completely limit
functionality randomly -- some servers will have reasonable collection
responses while others have XML responses.
This change mandates an XSLT transformation on the server (e.g. mod_xml). A
custom client doesn't have the option to tell the server, "hey, I want the
XML output because I can do neat things over here with it." And now I'm just
waiting for the response, "well, then we can look for the Accept header, see
if xml is supported, and return it then." Great. Yet more code to support
what is supposed to be fill-in functionality [the collection responses].
So. I'm -1 on this change. It can stay in while we discuss options, but it
will eventually be ripped out or fixed in some way.
-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
Received on Thu Jun 20 17:13:11 2002