Wow! I managed to piss of _two_Gregs with one commit! :-)
Greg Stein wrote:
>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.
>
I agree with all of that, but see below.
>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.
>
That's neither here nor there. Sure, it's a matter of server
configuration. So's access policy. I can well imagine setting up a
server in a closed environment where browser capabilities are known. Or
you could have two <Location> blocks pointing at the same repository.
>This change mandates an XSLT transformation on the server (e.g. mod_xml).
>
Um, it doesn't, because the default output hasn't changed, and the
transformation is done on the client.
> 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.
>
>
It's _meant_ to be ripped out eventually.
The Right solution is obvious -- mod_dav_svn should be able to push raw
data through mod_autoindex. But to do that, mod_autoindex must have a
pluggable data source, which it currently doesn't.In the meantime (and
in the absence of ViewSVN), people can play around with other options.
The whole point of adding that code was to have something to work with
and test while considering what we really need, that's all.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 20 19:54:44 2002