...
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.
...
The various plugins require DOM fragments to supply properties during construction, so the implementation will need to construct these fragments. If it's really possible to turn "simple" into "standard", the most sensible thing to do is just generate the "standard" XML and load that using the existing code.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 pluginThat also suggests perhaps doing this with a stand-alone tool that "creates" the real configuration based off of the simpler form, which introduces the possibility of leaving the SP itself alone. That also makes it simple to keep supporting config reload at runtime, since the simple format wouldn't ever be loaded directly. The only downside would be the extra generation "step", but it doesn't seem that difficult.
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.
...
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 This effectively replaces the ISAPI material plus provides for generation of a minimal RequestMap plus 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.
RequestMapper / Native Commands
The ideal would be to support both a simpler format for IIS and allow a stand-alone XML file with the existing format. The problem with that is the need to "combine" that information with the applicationId mapping information derived from the virtual host section. Since we're going for "simpler", I'm inclined to punt on that and add more material to the virtual host definitions to deal with the rest of the functions of the RequestMap.
Native command support for Apache and NSAPI would remain as is, by wrapping a "generated" XML RequestMap as they do now. So the goal here is only for an alternative syntax that would allow for the generation of that XML.
The sanest way of structuring this that I can think of, which actually introduces an interesting construct that the XML doesn't handle, is to have a set of "named" sections defining the RequestMap properties to attach, and then link to those sections from within the virtual host sections based on the path information to apply them to.
In other words, a section called protected could have key/value pairs like requireSession=1 and exportAssertion=1 (same as current options), establishing the settings that are in effect. Within the virtual host section, any "unknown" key values could be treated as path expressions whose value would be "protected", mapping them to the necessary section. The hardest part would be dealing with overlapping paths, since the XML format doesn't detect that, but it should be possible with some work. Regular expressions could be signaled with a '~' character, and would generate a PathRegex rule in the XML.