Preparing for eventual watcher pattern

doc/eventual/channel.md

@@ -0,0 +1,42 @@
+# Channel independence
+
+
+We should be able to return a disconnected channel that would connect on data set i.e
+```javascript
+	// EventualContext
+	var ectx = eventual.createContext(); // Creates a context that can be destroyed
+	ectx
+		.channel('named')
+		.on('something')
+
+```
+
+## TODO
+
+* Known bug/Idea - if we request a channel and emit it will only send in this channel context
+	Maybe we can create channels for listen purpose only, and ctx for broadcasting?
+	Maybe expose broadcast and leave the possibility for single communication, as:
+
+```javascript
+	var ctx1=eventual.createContext();
+	var ctx2 = eventual.createContext();
+
+	var hellochn = ctx1.channel('hello')
+	hellochn.on('msg',() => { console.log('hello ctx1'); };
+
+	// Same thing but for context2
+	ctx2.on('hello:msg', () => { console.log("Hello from ctx2"); });
+
+	// Now:
+
+	// Only it would call only local, 'hello ct1' would be printed
+	hellochn.emit('msg');
+	// (not implementd) IDEA: It would print, 'hello ctx1', and 'Hello from ctx2'
+	hellochb.broadcast('msg');			// channel prefixing, It would send 'hello:msg' 
+````
+
+	
+
+
+
+		

doc/eventual/context.md

@@ -0,0 +1,48 @@
+# Context
+
+What is a eventual context?
+
+Eventual context is basically an entry that can be destroyed with all underlying information:
+
+```javascript
+
+	var eventual = new Eventual();
+
+	var ctx = eventual.createContext();
+	var ctx2 = eventual.createContext();
+
+	// This will store the listener in the ctx
+	ctx.on('chan:chan2:chan3',() =>{
+		console.log("received");
+	});
+
+	ctx2.on('chan:chan2:chan3',() => {
+		console.log("fire");
+	});
+	
+	// This should fire events, and 'received' and 'fire' will be printed
+	//eventual.emit('chan:chan2:chan3');
+	ctx2.emit('chan:chan2:chan3');
+
+	ctx.destroy();
+
+	// Will only print 'fire'
+	ctx2.emit('chan:chan2:chan3');
+
+```
+
+### How it works:
+
+After context creation the context  will be pushed into the eventual registry
+each eventual context or channels will maintain a eventual reference.
+
+method destroy is an alias for eventual.destroyContext() it will remove itself from the registry
+
+
+
+
+
+
+
+
+

doc/eventual/watcher.md

@@ -0,0 +1,36 @@
+# Watcher pattern - eventual
+
+Case Loader wants to know if modules were installed by installer
+
+Events will not work because of order: ex
+
+1. Installer starts, 
+2. Install modules, 
+3. and emit "installed" event
+
+4. loader listens for installed event ----------  This will never get called since event was emited before
+5. then load modules
+
+
+#### Solution:
+```javascript
+ 	// hci-loader
+	// This will be fired right away with undefined if there is no value setted
+	loader_context.watch('hci-installer:installed',(value) => {
+		if(value == true) {
+			this.loadBundles();
+		}
+	});
+
+	// hci-installer
+	// This will store value in a contextual property and fire event for 'hci-installer:installed'
+	installer_context.value('installed',true); // Not that will send 'modname':context
+
+```
+
+It can be used for several other things, storing states, listening for things, event alternative events
+
+* values should be stored within context?
+* watchers same:
+
+

doc/ideas.js

@@ -2,6 +2,12 @@
 //
 //
 
+/*
+watcher and set pattern for any case of flags
+lets say loader wants to wait for installer state, can't be an event since it will
+
+
+
 
 
 commChannel with two points