On Jul 8, 2007, at 5:48 PM, Emmanuel Lecharny wrote:
Mark Swanson a écrit :
Emmanuel Lecharny wrote:
<snip/>
Still catching up -- working backwards... wrt the "problems"
1. I disagree that this file is complex. It's straightforward,
simple, and sensible. Perhaps more docs would make it easier for
folks but come on, this is light years ahead of other LDAP
configs. This _small_ XML config file is a _single_ file. I like it.
Create a simple howto with samples on how to configure it for the
most common use cases. Just enable folks to copy/paste the common
config options.
Well, from your poit of view, as a experienced user, yes, the
current server.xml is not too complex. But :
- for new commers, it's quite difficult to get in (and I must admit
that Dave has a point ith XSchema)
- and the current configuration won't reflect the next level of
configuration we will reach when all what we want to add into the
server will be done.
2. Please _PLEASE_ DO NOT put config info into ADS. Do NOT make me
use a GUI tool to configure ADS. I can't always make an X
connection to an ADS machine and it would be a lot of trouble to
map and route specific ports in front of the virtual IP router to
manage specific ADS instances from port 389. I really like being
able to edit the XML file with a text editor.
We will put the config into ADS _and_ you won't have to use a GUI
to configure the server :). Open Ldap works exactly the wame way,
using LDIF fiels to modify the configuration. Obviously, this is
quite a good solution.
Umm, really? You'd prefer to deal with ldif files for the server
config rather than the validatable-by-most-xml-editors xbean-spring
configuration files? So, whenever you edit something you get to
reload the ldif to find out if you made a typo? Are most ldap users
much more comfortable with ldif files than xml?
Anyway, we won't be able to please all the users ... But having the
configuration into the server will help a lot when dealing with
replicated servers (no need to login on N servers, we will have a
way to 'replicate' the configuration)
The replication seems like a plus for the store-in-ldap solution. On
the other hand it could turn into a way to break all the servers at
once rather than only breaking one in case the edit didn't work :-)
thanks
david jencks
Emmanuel
