subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "ServerDictatedConfiguration" by pburba
Date Tue, 03 Jan 2012 22:00:58 GMT
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 pburba:
http://wiki.apache.org/subversion/ServerDictatedConfiguration?action=diff&rev1=30&rev2=31

Comment:
Present several alternatives to the (flawed IMHO) single capability string.

  
  Over ra-neon/ra-serf, the client will receive the repository's configuration checksum as
part of the OPTIONS response.  It will request new configuration bits via a custom REPORT
request aimed at the repos-global report target (the "me resource" for HTTPv2, the "default
VCC" otherwise).  ra-svn will behave similarly, using the initial handshake/feature negotiation
phase for the repository's checksum delivery, and a new query for the configuration fetch.
  
- We plan to introduce a new capability string ("server-config") which clients should use
to announce to the server that they will honor the server's dictated configuration.  Administrators
may choose to use that string presence/absence in the list of capabilities passed to the start-commit
hook to determine whether to allow commits from certain clients.
+ We'll need a way for clients to announce to the server that they will honor the server's
dictated configuration.  The obvious way is via a new capability, so administrators may choose
to use the presence/absence of the capabilitiy in the  list of capabilities passed to the
start-commit hook to determine  whether to allow commits from certain clients.  There are
a few different ways we might want to procede however:
+ 
+ ||<tablestyle="width: 793px; height: 176px;">'''Capability/Capabilities'''||'''Notes'''||
+ ||A single new capability string ("server-config")||Simple, but isn't sufficient to differentiate
from later releases which might support new configuration options. ||
+ ||New capability strings per supported option (e.g. "server-config-autoprops", "server-config-ignores",
"server-config-store-plaintext-passwords")||Solves the problem at hand neatly, allows future
releases to add new configuration options, but while we're thinking about this space, haven't
you ever wished for...||
+ ||New capability for each minor release (e.g. "client-version-1.8")||...A way for the client
to communicate it's version to the server?  This goes beyond what is needed for server dictated
configuration, but why not put it in place now?||
+ ||New capability for each patch release (e.g. "client-version-1.8.0")||Ditto, but if knowing
the minor release is good, kowing the patch release must be better no?||
+ 
+ 
+ 
  
  === Server-side Changes ===
  ==== Configuration storage ====

Mime
View raw message