Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for 
change notification.

The "ServerDictatedConfiguration" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/ServerDictatedConfiguration?action=diff&rev1=22&rev2=23

Comment:
Add a big concern I have about the authn-related configuration stuff.

  The most logical format for server-side configuration is to use the INI file 
format[1] which is already employed for several other purposes across 
Subversion.  And the most logical location to put those INI files is in 
''${REPOS_PATH}/conf/'' somewhere.
  
  [1]The actual syntax is documented in the default README file created by 
Subversion in the per-user configuration area (e.g. 
%APPDATA%\Subversion\README.txt on Windows and ~/.subversion/README on *nix) or 
can be found in the Subversion source code in 
[[http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/config_file.c|config_file.c]]
 -- see svn_config_ensure().
- 
- 
  
  === Client-side Changes ===
  ==== API changes ====
@@ -136, +134 @@

   1. Per-machine runtime configuration (''/etc/subversion/*'')
   1. The system-wide Registry values (Windows Only)
  
+ === Concerns ===
+ Most of this idea of server-dictated configuration seems sane.  But there's 
one bit that stands out as flatly ridiculous -- the server dictating how the 
client stores authentication credentials.  No matter how I look at this, it 
feels wrong.  Not just wrong, but unique amongst open source client/server 
software.  What's more, I'm concerned that by the time any client would have 
consulted the server to ask about its configuration, it will have already 
cached the very authentication credentials it just used to talk to that server. 
 ~cmpilato
+ 
  === Deferred Goals ===
  As with any long desired feature (issue #1974 is over seven years old) there 
are differing opinions on what "Server Dictacted Configuration" should entail.  
This section tracks functionality we are currently ''not ''planning to 
implement in the first phase -- Obviously this is subject to change.
  

Reply via email to