reorganizing

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

7 files changed, 251 insertions, 0 deletions

diff --git a/notes/design b/notes/design
new file mode 100644
index 000000000..af134dbdf
--- /dev/null
+++ b/notes/design
@@ -0,0 +1,99 @@
+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
new file mode 100644
index 000000000..e3433b396
--- /dev/null
+++ b/notes/execution
@@ -0,0 +1,28 @@
+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
new file mode 100644
index 000000000..ce6fe7d86
--- /dev/null
+++ b/notes/features
@@ -0,0 +1,13 @@
+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
new file mode 100644
index 000000000..3bd1e9d86
--- /dev/null
+++ b/notes/goals
@@ -0,0 +1,17 @@
+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
new file mode 100644
index 000000000..2b7fa5957
--- /dev/null
+++ b/notes/issues
@@ -0,0 +1,43 @@
+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
new file mode 100644
index 000000000..052828dc8
--- /dev/null
+++ b/notes/language/notes
@@ -0,0 +1,7 @@
+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
new file mode 100644
index 000000000..899040d9d
--- /dev/null
+++ b/notes/notes
@@ -0,0 +1,44 @@
+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