Orchestrator Supervisor 0.1

[taboca]

We need to land a solution that can keep track of events using HTTP/URL channels. This may involve:

1) Channel Registration and Management ( version 0.1 with no UI ) 2) Channel Loader Accounting
2.1) Processing of Events that can do Widgets Governance ( inserting, removing ) 2.2) Session Management -- we need to keep track of events executed and incoming/running events so that when the system crashes we know how to recover. 2.3) From this, we may open a door to remote monitoring, logs etc

We may need a solution which scales over time. For example the ability for a widget to register more events -- we have to think this a bit, maybe land first, test and kill the feature later if it is too overboard and in case it's not a hassle to implement. A case would be

Channel 1 { domain-apply: "selector: html body table.td; channel-url:http://www.taboca.com/source.xml processor: reload(10secs); }

This model allows the commands from channel-url to do many sorts of mutation to the scope of the document under the html body table td. However normally html body table.td is not a document, so here we have an open discussion. We are simply treating these as if they were sepeated documents for now, as an exercise. In a way this model is a solution that can assocated remote DOM events to certain nodes in a given DOM tree.

[taboca]

The system needs to accept events (coming from the local or remote resources) that can cause IFRAME insertions in the DOM. Today, we have a /lib/choreographer.js function called "register" and it's a simplified proposal of that model which was originally designed with an idea — to track the loading of components.

Since we have more dynamic use cases, we need to have a more dynamic way to add/remove components over time — some of the needed features:

• Ability to add a new iframe to a given grid
• Ability to remove existing components
• Ability to modify the grid state based in events from the inner components?

Use cae:

We have a document with the following structute

+---------+
|  a  |  b |   
+---------+

Into b, we load a comonent B1 which is a calendar ; After certain time the calendar requests to be expanded; This is done via the calendar simply saying its' desired size to the parent. If the parent has a rule, let's say "recalculate based in flex weights" then it does the job — so for example the grid is resized to the following:

+-----------+
| a |    b   |   
+-----------+

After a given time the B will be replaced with a new component, A. But we do not want to insert this new component C into the current B state / size, we may want to insert into the prior sizing for b, so first we may need to recreate the state of grid:

+---------+
|  a  |  b |   
+---------+

Then to make the insertion:

+---------+
|  a  |  C|   
+---------+