[Config4gnu-developer] preliminary observations from apache/proftp

[Justin Y. <ju...@sk...>]

On a side note, I looked at the URL you sent me Jason and I got it to compile but I'm messing up the pointers in the function call...  

I've been looking over Apache's configuration format to figure out what needs to be done to support it.  The good news is that apache 2 and apache 1.3 are very similar configuration-wise, so we shouldn't have to do much to support one once the other is supported.  Also, proftp is  going to require about the exact same support that apache will, so it too will should easy to support once the framework is in place.

Here are some of the more major things I've observed that we can't handle with Apache:

1) Inherited defaults

We have no way of doing this for samba either, but apache makes heavy use of them.

2) Conditional validation/defaults

Some directives or values of directives are only valid under certain circumstances, for example a VirtualHost block can only specify an address and port that have already been specified in a Listen directive.  Another example is that for apache 2, the default number of threads/processes running to handle requests depends on what type of threads the server is configured/compiled to use.  

There are a bunch more important examples of this where the value of another directive changes whether other directives are allowed or make sense.  I know samba had a few obscure cases of this, but we pretty much ignored it temporarily because it wasn't as big of an issue.  Some type of value-based validation language will need to be added at some point.

3) Hierarchy of XML (in the sense of Ifdefine/Ifmodule)

Some directives are only applied if the test on the IfDefine or IfModule block they're in is true.  There are problems with both possible solutions, either nesting them inside an ifdefine or ifmodule tag in the xml, or having ifdefine_start and ifdefine_end tags surround them.  


In the second case, the waters will get very muddled if we don't put directives in an IfDefine or IfModule section as children of that section.  For example, consider the following:

<VirtualHost 10.1.1.1>
   <IfDefine BOBS_SERVER>
      ServerName bobsserver.com
   </IfDefine>
   <IfDefine FREDS_SERVER>
      ServerName fredsserver.com
   </IfDefine>
</VirtualHost>

So, both servernames are direct children of the virtualhost node in the XML, which one gets addressed when you lookup virtualhost.servername ?  To properly handle this, we really need a system smart enough to check which value should be addressed based on the tests in the IfDefine.

For the first case of putting directives as children of ifdefine/ifmodules, it is difficult to address them, as you'd have to request global.ifdefine.mydirective instead of global.mydirective, which will cause a lot of problems.  We could solve this one way by making ifdefine a special type of section, sortof a "semi-transparent" section whose children can be addressed as if they were children of the transparent section's parent.  Of course, we'd need to determine whether the test is true or not to determine whether or not to allow addressing to go *transparently* through, if its false then you'd have to address is using global.ifdefine.mydirective.

4) VirtualHost/Directory/Filename hierarchy

First off, the easiest approach is to directly translate the config file into XML structured the same way as it is.  It also seems that reorganizing the XML is not going to work for the reasons we talked about on the way back from Commnav, there's not a 1 to 1 mapping.  I *think* that it may be possible to avoid reorganizing altogether.  

What if we display the config file basically as it is natively, and then we'll need a system to perform the pattern matching against given files/directories to let users see the settings for that file/directory.  Of course, we could also auto-create a list of those files/directories specifically mentioned in the config file which would handle most, if not all, of the things the user would want to see.

When a user wants to add/edit/remove a setting, they need to specify whether the change should apply to everything, just a virtualhost, a directory, or a file, and if there are more than 1 matching directory/file sections, which of those it should apply to.  Additionally, they would specify say, if you want to change the default global setting to not display directory listings, whether or not other directory/virtualhost/file sections should have any contradictory settings removed.  Something like an "Apply change recursively" checkbox would do the trick.

I think that maybe boiling apache/proftp down so that you have a browseable directory tree showing all the values might be too abstract.  The thing that's really got me thinking this way is that at some point you have to ask the user about the scope of the change they're making.  Maybe there are ways to do that in a completely tree-based approach, perhaps it would even be possible/better to implement 2 different views...  

I'm not sure about these things, but they're some ideas I've come up with.  I probably need to come up with a few drawings so that some of this makes sense.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com