...
Not needed for Apache, but no way to avoid something comparable for IIS.
Could maintain a separate XML file, but seems better to come up with a non-XML alternative because of the need to reference hostname(s).
A simpler format might also be "pluggable" into standard config.
The properties themselves are generally "flat" and simple to express without XML, so the change is in how to associate them with content without the nesting but without implementing htaccess in IIS.
ApplicationDefaults/ApplicationOverride
...
This leads into the problem of how to specify the configuration style in use, and support the competing goals of using the simple form by default in new releases, but supporting the standard form after an upgrade with no special additions. The configuration pluggability layer has features designed to allow alternative implementations, but those features would require setting environment variables or using special commands and options. So the fallback position would be to stick with the default plugin type of "XML" and just auto-detect the format from inside that plugin.
Virtualization
Most of the complexity now comes from the support for virtualization of SPs and application overrides for virtual hosts or paths. It would be really simple to dump all of that, but that might be going too far and prevent significant use of this simpler configration.
Sketching out how this could work, a list of vhost "identifiers" in a vhost section could point to dedicated sections for each vhost. Those sections could include settings such as:
- canonical hostname
- aliases to permit (on IIS at least)
- scheme(s) and port(s)
- entityID override (perhaps paired with optional "prefix" to allow path-based vhost subsets)
On non-IIS, this should all be optional (unless entityID override used). For those cases, the information to associate with the current request should be derivable in the same way it is now, which is outside the configuration of the SP proper. So this effectively replaces the ISAPI material plus provides for generation of ApplicationOverrides with virtual entityID at either the vhost or vhost + path level.
None of this addresses the RequestMap itself, which is a harder problem, but separates that piece from the applicationId -> ApplicationOverride function of the current RequestMap.