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" _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel