Hi Dave,

I have not spent much on this thread so I may not be up to date however I think I can answer
some of your questions below.

On 7/3/07, David Jencks <david_jencks@yahoo.com> wrote:

On Jul 2, 2007, at 11:55 PM, Emmanuel Lecharny wrote:

> Hi guys,
>
> sorry for the "deafening silence" ... We were quite busy those last
> days, up to a point we let this important mail dying silently ...
>
> ok, I agree with David that the current server.xml is, to say the
> least, not very easy to handle, as it does not carry a lot of
> semantic.
>
> Now, from our users perspective, we have two problems :
> 1) current users don't manipulate a lot this file, as you don't fix
> something which work, as soon as it's complicated to male it work
> again, due to the complexity of the current configuration file ( kind
> of circular situation ... )
> 2) new users are simply afraid to touch this configuration file,
> because it's too complex...
>
> We have two ideas to help solving those problems :
> 1) Apache Directory Studio contains a GUI which helps to manupulate
> this file. Not sure that users are aware of that ...
> 2) we really want to move almost all of this configuration into the
> DIT in the next few months, so that we will be able to avoid having
> such a massive configuration file
>
> The second solution will obviously be coupled with a new version of
> the first one.
>
> I would add that there is no good solution to such a problem. We went
> from property file to spring configuration because the property file
> was ugly and didn't carried enough semantic. Now it's the same problem
> again. Pushing all the configuration into the DIT won't add extra
> semantic... This is a dead end. Wat I would suggest in this case is
> the least we change the configuration, the more likely users will get
> used with it. And I pretty much favor a move to the DIT for the sake
> of completeness : using LDAP to manage itself.
>
> Let's face the reality : whatever level of semantic you add to a
> configuration file, you will _always_ need a good doco and nothing
> will replace the RTFM credo...

Having a grammar for the config helps a lot in my experience.  xml
schema is the only grammar language I'm familiar with that is
reasonably comprehensible and has a lot of easily available grammar-
aware editors.  I think writing your own language and tools to edit
it may not necessarily make a lot of friends.


I don't understand a couple details of this plan...

- Isn't there a bootstrap or chicken/egg problem with getting a
server to the point of being able to read its own configuration?  Or
is the plan to bootstrap a simple server with no external
connectivity, use it to read the config and start the real server,
and then throw it away?

Something like that. The thing is you don't start the entire server but just start
up the system partition to look up the configuration.

- Does this mean that the spring xml files or xbean-spring xml file
will be replace by a server.ldif file, in terms of being able to edit
the configuration?  Or is the plan to force anyone who want to look
at or modify the server config to fire up Apache Directory Studio?
It's hard for me to see either of these as an advance over editing
even the current server.xml files.  Being able to edit the server
config in vi or emacs has its advantages.

- Is the plan to completely ditch spring and write your own wiring
framework?

I'd like to load the configuration out of the DIT and not bother with spring at all.

Alex