Moved documentation to project website.

git-svn-id: https://reductivelabs.com/svn/puppet/library/trunk@477 980ebf18-57e1-0310-9a29-db15c13687c0

7 files changed, 0 insertions, 251 deletions

diff --git a/notes/design b/notes/design
deleted file mode 100644
index af134dbdf..000000000
--- a/notes/design
+++ /dev/null
@@ -1,99 +0,0 @@
-Phase I:
-	Context
-	The only place you can discover non-object state
-		e.g., hard classes, schedules, hostgroups, etc.
-
-Phase II:
-	Objects
-	Build the objects up based on developed Context
-	This step stores triggers with the objects but cannot yet react to them
-
-Phase III:
-	Run
-	Results in a list of operations
-
-Phase IV:
-	Check:
-	Results in list of dirty objects
-
-Phase V:
-	Fix
-	Does all of the work
-	Results in triggers being pulled
-		(triggers are just operations, aren't they?)
-
-Phase V:
-	Run triggers
-	Might result in more triggers
-		mmm, recursion
-
-Phase I:
-	Build the data structures which we will or will not use
-
-Phase II:
-	Decide which data structures we will use, and add all hooks for triggers
-	and such
-
-Phase III:
-	Analyze the system for compliance with what we think it's supposed to
-	look like
-
-Phase IV:
-	Do all the work that we've determined needs to be done
-
-Phase V:
-	React with any triggers, ad infinitum
-
--------------
-The entire thing needs to be OO based, and every object needs to have both
-an 'as_string' and an 'as_boolean' method that gets implicitly called.
-
-Methods each active object needs to have:
-	boolean
-		is the object configured
-	on
-		enables the object
-	off
-		disables the object
-	prepare?
-		uh, does stuff in preparation
-	check
-		compares configured state to server state
-	converge (still a bad name)
-		converges server state to configured state
-
----------------
-What kind of builtin objects do I need?
-
-FileConfig
-	Straight monitoring of a file and verifying on-disk config (perms, et al)
-	Classes to set or actions to trigger if the file changes
-		need to differentiate inode changes from data changes
-FileChunk
-	Some kind of format that can be filled in with values
-		Needs to be able to specify fixed or variable fields, yuck
-CreatedFile
-	Collections of chunks
-		Do the chunks have to be ordered?  Does that order come from order in
-		the file or some other way?  Probably have a separated "ordered file"
-		object
-	Compares to the file on disk
-		It'd be really, really nice to have this in a database somewhere
-	Classes to set or actions to trigger if the file changes
-
-Process
-	Describes a running process to the greatest extent possible
-	Classes to set or actions to trigger if anything happens with the process
-
-Link
-	something similar to cfengine's Copy, something that says 'always make sure
-	this file is pinned to some other file'
-		It'd be cool if this system would automagically pin every file on the
-		system to a central repository, so you really could say every file
-		on the system was managed
-			or at least, every file that exists in the central repository
-
-Package
-	Maintains the list of installed packages, and has some means for retrieving
-	packages from a central location
-
diff --git a/notes/execution b/notes/execution
deleted file mode 100644
index e3433b396..000000000
--- a/notes/execution
+++ /dev/null
@@ -1,28 +0,0 @@
-execution path:
-
-parse the entire file recursively
-	imports are definitely inline
-
-
-
-what I'm trying to resolve is:
-	can the entire thing be parsed and then executed, or do the objects
-	need to be able to take into account the results of execution?
-		most other languages make a clear differentation between values
-		and executables, so why shouldn't we?  as long as we support some
-		kind of executable, it should be fine
-	i need to keep in mind that the definitions of operations and objects
-	will not actually change as a result of execution, merely the details
-		does this matter?
-
-objects are created during parsing
-	this means that i have the choice of:
-		--not creating operations at parse time
-		--dealing with this nasty interface to parse-time operations
-			if we don't have this nasty interface, then execution can't affect
-			the contents of operations
-				would that make sense? a file with multiple operations whose
-				different operations can change the values
-
-here's the crucial question:
-	is there a difference between executing the code and performing the operations?
diff --git a/notes/features b/notes/features
deleted file mode 100644
index ce6fe7d86..000000000
--- a/notes/features
+++ /dev/null
@@ -1,13 +0,0 @@
-High-level:
-	ability to define many objects in one section, e.g.:
-		Files {
-			"/etc/inetd.conf" = { .... }
-		}
-
-	ability to set local and global defaults for a section:
-		Files {
-			template = { o=root, g=root }
-			"/etc/inetd.conf" < template = { ... }
-		}
-
-
diff --git a/notes/goals b/notes/goals
deleted file mode 100644
index 3bd1e9d86..000000000
--- a/notes/goals
+++ /dev/null
@@ -1,17 +0,0 @@
-Lists and iteration
-
-consistent syntax
-
-datatype sigils?
-
-module interface
-
-references?
-
-eval?
-
-multiline strings
-
-all syntax supported anywhere
-
-ability to evaluate any object for truth or falseness
diff --git a/notes/issues b/notes/issues
deleted file mode 100644
index 2b7fa5957..000000000
--- a/notes/issues
+++ /dev/null
@@ -1,43 +0,0 @@
-1. How do I specify delayed evaluation?
-
-This is essentially a question of a simple syntax for stored procedures.
-
-2. How do I specify "call this method on yourself"?
-	ruby's method works relatively well, but i wish i could leave out
-	the "|me|" stuff
-
-This is just a bit more complexity onto the stored procedure syntax.  It is
-different than storing a non-object procedure, so the syntax does have to
-reflect that.
-
-3. Do I support implicit lists, e.g.:
-	cron.user('root').each { do stuff }
-
-	something like "any instance method when called on the class produces a
-	list of all instances which meet the criteria of the call"
-		this gets muddied if i want to use variable sigils
-
-	if i do support lists, do i try to support roll-back?
-		definitely not in the first version....
-
-	or rather, if i support lists, do i support them as facts?  do 
-	lvalues in this case ever actually do anything, such that they would need
-	to be rolled back?
-
-	really, this isn't something that would be rolled back, because i'm stating
-	that something is a certain way based on logic in the script, not the state
-	of the real system
-		at this point; that might change...
-
-4. The difference between object initialization and later method calls
-
-5. Why _shouldn't_ I just use Ruby?
-	no standard 'to_b' method
-	specifically ordered
-
-6. Parsing ordering
-	Will I actually be able to abstract that aspect?  I kinda doubt it.
-
-7. Module interface
-	I need something, preferably something that has hooks to other languages.
-	I can begin without one, but there definitely needs to be support for it.
diff --git a/notes/language/notes b/notes/language/notes
deleted file mode 100644
index 052828dc8..000000000
--- a/notes/language/notes
+++ /dev/null
@@ -1,7 +0,0 @@
-Selectors:
-    should they always error if a host interprets without a value?
-        e.g., should they always have what amounts to a default?
-            otherwise, we'll get valueless statements
-
-Truth:
-    we need to handle true/falseness
diff --git a/notes/notes b/notes/notes
deleted file mode 100644
index 899040d9d..000000000
--- a/notes/notes
+++ /dev/null
@@ -1,44 +0,0 @@
-things i need:
-	locking
-	automatic reexecution for any object
-		with a reread of all config stuff? is this even possible?
-	state maintenance
-	event handling and subscription
-	failure propagation
-
-my basic process:
-	load the configs
-		create each object tree in a stack
-		register each event, with subscriptions and paths
-		register all callbacks
-	run a recursive check on each tree
-		depth-first? configurable?
-		do checks result in events or methods or what?
-			should checks return methods which just get executed in order?
-			but then what do events cause?  don't i have to register callbacks?
-			what if the callbacks cause a change which kicks off an event? can
-			i worry about infinite loops?
-
-			and i can't just register all the callbacks upfront
-				but all callbacks will be registered before any work is done
-	execute each fix
-	execute resulting callbacks
-	destruct each object tree
-
-hmmm
-	do i need object trees with callbacks? how do they relate?
-	currently they just seem to give containers first crack at responding
-	to an event
-	i'm looking for closure-like performance from each tree
-	how much should the checks know? they obviously shouldn't know much
-		they should not need to know the event that a fix will kick off, the
-		fix should know that
-	so it looks like i'm trying to decide between idempotent operations and
-	idempotent processes
-		if a fix gets called, it should just fix; it shouldn't need to check
-		whether it's necessary
-	tree vs array
-		should everything stay in the tree? what does "containment" really mean?
-			should i just save containment for later? because it's really about
-			forcing all changes to go through the container, rather than
-			direct modification