Delete: doc/why-is-this-different-from-LDAP

}(Logical change 1.340)


git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@1402 ce84e21b-d406-0410-9b95-82705330c041

1 files changed, 0 insertions, 30 deletions

diff --git a/doc/why-is-this-different-from-LDAP b/doc/why-is-this-different-from-LDAP
deleted file mode 100644
index f670ebe21..000000000
--- a/doc/why-is-this-different-from-LDAP
+++ /dev/null
@@ -1,30 +0,0 @@
-1. what we aren't
-
-I feel the need to write this to describe why our approach isn't the
-same as the LDAP approach. When designing any metadata-based
-configuration management system, there is substantial temptation to
-start describing all aspects of the system that are relevant to system
-configuration. This approach leads to a few things. First, there are
-many long discussions that center around the proper representation
-for particular constructs. (ie, what attributes does a network
-interface have) The second outcome is that configuration details that
-might get used are typically included. This stems from the desire to
-have a comprehensive solution. The third, and most useful outcome is a
-large knowledge base from which many details of system configuration
-can be queried. This, in general, is a noble goal, but tends to
-require a lot of pain to get there. 
-
-Switching to a BCFG1 install involved a good amount of pain/effort in
-order to classify software components into categories dictated by our
-model. I am not sure how well a more complicated process would be
-accepted by any user community. 
-
-2. how to do better
-
-Any system will have complex portions of configuration, and
-site-specific oddities. A single, simple description scheme certainly
-won't provide the flexibility required to model complex
-interdependencies. The approach we are taking is to provide a simple
-scheme while allow arbitrary logic to be embedded. (generators) Using
-this scheme, simple configurations remain simple, and complex
-configurations are possible.