[Sugar-devel] Unified Objects (was Unified bundles)

[Michael Stone]

Wade,

Here are a couple of /very/ quick thoughts for you. Please let me know which
ones are helpful and which are simply confusing (or misguided).

Michael

----------------

The basic premises of this rant are that 

   "we need to be able to mix, match and dissect activities"

so therefore activities should consist of remixable "facets", i.e.

   "nestable layered segments".

Furthermore, 

   "Filesystems rock for nestable layered segments, so let's use more of them!"

----------------

Now here's a mess of ideas from which these three basic intuitions originate:

1. It would be nice to be able to generate various views of "what the user can
do" with shell globs rather than by writing complicated queries over in-memory
data-structures that have to be fully loaded and locked into RAM before you can
render anything...

2. Activities need to expose their API to the shell. In particular, we /need/
to be able to get an activity to self-test a system for deps, to run
non-graphical tests, to run graphical tests, to run network tests, to run a
demo or tutorial of itself, to show its source, ...

3. One interesting way to think about (1) and (2), which I have previously
discussed with Eben, is in the context of the Plan 9 plumber. Go read about it.

4. Modifying activities is currently a pain in Sugar because you have to reboot
sugar for changes to take effect. Let's use inotify/dnotify/FAM/.... or
git-like fast change detection to fix that.

5. Scott has worked out some cool ideas for browsing, tagging, and version
control in his journal2 and olpcfs2 work. Scott -- did you ever implement the
GIO-based launcher?

6. Filesystems can be efficiently and incrementally shared over networks in
standard ways; e.g. 9P, rsync, cerebro. Furthermore, we can "ride the wave" of
advances in network filesystem research over the coming years.

7. If activities are supposed to have per-activity or even per-instance
permissions, then Rainbow really needs a way to authoritatively distinguish
activities (instances). This certainly means that some control of permissions
is needed. If networks are involved, then this also means cryptography.
Naturally, the crypto can be optional, can be implemented later, etc.; however,
the spec still needs to define something workable. The major thing needed at
the moment is a "per-thread" public key to be used to sign manifests of
updates and a "minimum cover" over which to generate a manifest. (We might also
specify a "more inclusive cover" as a handy error-detection mechanism.)

8. Pursuant to (7), it would be really good to use the same format for journal
entries as for activities themselves. That way, the search, plumbing, network
browsing, version control, permissions, and crypto stuff can be shared.

9. A rough list of facets that this format should expose: 

   translations, 
   HTML help, 
   automated tests, 
   permissions, 
   integrity data,
   arch-specific optimizations, 
   public APIs (incl. data, e.g. sound or icon libraries) for other activities, 
   and "UI continuations", i.e. "resumable instances", i.e. "Journal entries"