diff options
Diffstat (limited to 'docs/old')
| -rw-r--r-- | docs/old/containerization | 58 | ||||
| -rw-r--r-- | docs/old/internal-coupling | 107 | ||||
| -rw-r--r-- | docs/old/startup | 52 |
3 files changed, 217 insertions, 0 deletions
diff --git a/docs/old/containerization b/docs/old/containerization new file mode 100644 index 0000000..8a40637 --- /dev/null +++ b/docs/old/containerization @@ -0,0 +1,58 @@ + +== Problem: Containerization == #1992 + + Activities need to be created inside containers. + +Situation: + + "Activities" are launched as follows: + + 1. Clicking on an activity launch icon in Sugar triggers the + `sugar.shell.view.frame.ActivitiesBox._activity_clicked_cb' callback which + in turn fires off a call to `sugar.shell.view.start_activity' with the + corresponding service name. + 2. `sugar.shell.start_activity' calls + `sugar.activity.activityfactory.create()' which constructs a + `sugar.activity.activityfactory.ActivityCreationHandler', initialized with + an `ActivityHandle' describing the activity being started. + 3. The `__init__' method of ActivityCreationHandler connects to the DBus + session bus, uses a well-known name to locate an appropriate + ActivityFactory _DBus object_, and calls this _DBus object's_ `create' + method. + (The ActivityCreationHandler also installs callbacks to log the success or + failure of the attempt to launch the activity) + 4. The appropriate `ActivityServiceFactory' DBus service is automatically + launched by DBus from a service file if necessary. Then it's `create' method + is dispatched, which results in the activity itself being constructed and + presented. + +Plan: + + We will modify the ActivityCreationHandler to call over DBus to Rainbow. + + P1. Replace step (S3) with + + 3b. The `__init__' method of ActivityCreationHandler connects to the DBus + session bus, locates the `org.laptop.security.Rainbow' service, and calls + the `create_activity' method of Rainbow's `org.laptop.security.Rainbow' + interface. + + +Followup: + + F1. Design and implement the appropriate method in Rainbow. + + F2. Step (S4) is now cruft and should be cleaned. + + F3. Talk to Marco about how he thinks this really ought to be done. + + --- + + F4. Marco agrees with our proposal so it can move ahead once we're ready to + integrate Rainbow into the builds. + + F5. Bert Freudenberg would like us to update a wiki page and rewrite + sugar-native-factory.c for him. + + F6. However, Michael is not comfortable depending on the glib/gobject mainloop. + How long until we can get a libevent-based mainloop? (or move away from DBus?) diff --git a/docs/old/internal-coupling b/docs/old/internal-coupling new file mode 100644 index 0000000..baaaf29 --- /dev/null +++ b/docs/old/internal-coupling @@ -0,0 +1,107 @@ +== Problem: Internal Coupling, Interfaces, and User Experience == #??? + + The last few weeks of broader use of the rainbow codebase have revealed three + problems that we need to fix in preparation for broader deployment. + +Situation: + + First, olpc-update is too strongly coupled to Rainbow. This is a problem + because it means that it's hard to modify either piece of software without + unintentionally breaking the other. + + Next, Rainbow does not have a workable user-interface. Users of the software + have universally been unable to follow or to capture rainbow traces and are + frequently frustrated because rainbow fails offer human-readable explanations + of why it is failing. Two important facets of this issue are (the violations + of the Principle of Least Surprise and the Principle of Silence) and (you can + only interpret the traces if you know exactly what the trace is *supposed* to + be). Also, the traces are not packaged in form convenient for uploading to me + or, better, automatically aggregated. + + Finally, Rainbow's internal interfaces are too strongly coupled. This hinders + development because, without a test suite, console entry points, and + cut-points (in the AOP sense), it's very hard to modify the software without + understanding the whole code base. In particular, you can't really produce an + known good initial configuration, then iterate changes against that + configuration). + +Thoughts: + + I intend to separate olpc-update out from rainbow by splitting rainbow up + into a pipeline of scripts, probably organized along the current 'stage' + boundaries, that more exhaustively verify their starting and ending + assumptions. + + This decomposition will accomplish several things: + + 1) it will allow me to properly split olpc-update into a separate package and + should reduce code-breakage resulting from changes made to one component that + violate the assumptions made by a different component. + + 2) it will give me a vehicle for automatically collecting trace-data from + third-party users - I will simply ask them to exercise the shell pipeline + through a wrapper that records full traces, that nicely packages them, and + that attempts to send them to me. + + 3) it will clarify the locations in the design in which outside data is + processed and it will document the protocol by which these interactions + occur, e.g. by forcing these data to be passed through introspectable media + like files, environment variables, and command-line options + + 4) it will clarify the life-cycle of contained applications + + 5) it will provide a better opportuntity to exhaustively verify the + assumptions of each stage before continuing + + 6) it will make it easy and robust to start using a prototype process simply + by adding a wrapper to the chain + + +Downsides: + + * It adds a lot of option-parsing complexity + - The interfaces need to be documented anyway, and being able to pick up + part-way through an interaction / single-step could be a big plus + * It probably uses more resources than the current architecture + - The current architecture is just not adequately transparent; therefore, + it can be seen as a premature optimization. + - Also, if it means that we get prototypes, we probably win. + * it's not clear that it will actually be easier to give good user feedback + - it will be easier to debug, though, because you can start part-way + through and because you don't have to work *through* sugar to try + things. + - one could, for example, experiment with new pieces of isolation without + dealing with Sugar and the Terminal. + * do we have any data that we have to communicate backwards? If so, how are + we going to accomplish this? + - perhaps we could take the python-web-server idea of having a response + object that you piece together and ultimately return + - The chaining model is basically a linear graph of continuations + We could expand on this by putting together a more interesting graph; + e.g, by adding failure continuations + * why not go with a web-server? + - It still feels too monolithic and inadequately transparent to me + I really want to be able to examine the intermediate state of the + system with find and grep. + +Model: + + The basic model being proposed here is to use the filesystem as an abstract + store, to regard individual shell scripts as being fragments of an overall + program (written in CPS) with *well-defined interfaces*, and to thereby + expose the overall computation being performed to analysis by normal unix + filesystem tools. + +Questions for the Model: + * Are the individual chunks are supposed to execute atomically with + respect to one another? + +Questions for the Store: + * Is the store a naïve Scheme store or is it like the C heap? + * Does the store preserve old bindings for inspection? + * Perhaps it records the sequence in which bindings are added? + * Can it record who made a binding, and why? + * Thread-local or global? + * Configurable location? + * File-system or environment-variable + tempfile? + * Typed or untyped? (Pickles, JSON, repr)? diff --git a/docs/old/startup b/docs/old/startup new file mode 100644 index 0000000..15d96c7 --- /dev/null +++ b/docs/old/startup @@ -0,0 +1,52 @@ + +== Problem: Startup == #1988 + + Rainbow needs to be started before the first activity is started, so that it + can be ready to go when Sugar starts launching activities. + +Presently: + + The startup sequence looks something like: + + 1. `/etc/inittab' specifies that the default runlevel is 5. + 2. Upon entering runlevel 5, the DBus system daemon is started with priority + 22. + 3. `/etc/inittab' specifies that `/sbin/olpc-dm' should be started on + runlevel 5. + 4. `/sbin/olpc-dm' does some basic configuration of the terminal, language + environment, and the session (e.g. does a PAM login); then it logs in as + user `olpc' and runs `startx'. + 5. `startx' runs `xinit' which reads through /home/olpc/.xinitrc, does some + further graphical configuration, and then exec's `sugar'. + 6. `sugar' is a script that uses `dbus-launch' to start the DBus session daemon. + 7. The session daemon, once started, runs its argument `sugar-shell' with + appropriate environment variables. + 8. `sugar-shell' brings up Sugar. + + NB: Blizzard suggests that the current startup is hackish and should be + changed. + * In particular, we should use something less vulnerable to + modification than .xinitrc to start up. + * Also, he said that rc-scripts are going away to be replaced by a + monolithic start script. + +Plan: + + In the first iteration, we will simply launch Rainbow via rc-script at a + higher priority than `messagebus'. Since `sugar-shell' presently records its + DBus session bus's address to a `session.info' file, we will simply read this + file to acquire access to the main DBus session bus. + +Followup: + + Ivan suggests that we use `init' to start and respawn Rainbow. + + "Creating an Unkillable Process", Silas Brown, Linux Gazette #139, 2007 + http://linuxgazette.net/139/brownss.html + + gives a nice overview of how to do this in a hardened way. + + In the longer term, we may want to make the session bus talk to Rainbow in + some other fashion, for example by enclosing `sugar-shell' in a security stub + or by bringing the session bus up entirely separately from X. + |