Talk:Activity bundles

How to embed external applications?

From the LWN interview with Jim Gettys:

Chris' team is putting together a python based environment 
(into which conventional applications can be embedded) 
aimed at young children, temporarily called "sugar" (...)

How does this "embedding" work? How would a simple python "wrapper" script look like that embeds a simple X app?

Bundle activities in filesystem images?

Why not pack the entire bundle into a "disk image", e.g., using (z)isofs or cramfs? Hence, one application would be exactly contained within one file (similar to AppDirs, but one file instead of one directory).

This image would be mounted at the runtime, and unmounted again after usage has ended.

That way, the bundle becomes more "robust" (in the sense that it is read-only and cannot alter itself), plus it can be more easily exchanged (e.g., via mail/wlan) without the need to re-package it.

The impact of the additional overhead on speed is minimal, as my tests have shown.

I am in the process of providing a demo implementation. Some ideas are also provided on http://klik.atekon.de/wiki/index.php/OLPC -- [probono]

Bundle versioning? Bundle member versioning?

Will component members of a bundle be versioned?

If a computer joins an activity, and discovers that it has an earlier bundle in place (rather than a missing bundle), will it import the newer bundle? In other words, will a newer bundle version "percolate" to all who join an activity? -- [kritchie]

If a bundle is not a single (monolithic) file, can the outdated computer import just the newer members of the bundle to bring its own bundle up to date without importing the whole bundle? -- [kritchie]

Version Keys: Interface Version Key vs. Build Version Key

On reviewing the .info structure, I am wondering why we don't have an *interface* version key (IVK). An IVK is a key that changes *only* when a component's "contract" changes with regard to either the interface structure (signature, parameter usage, etc.) or the agreed and expected functionality. Thus, newer builds that may be more efficient or have other performance benefits but which do not change the contract could have a newer *build* version key (BVK) while their compatibility remains unchanged (signified by no change in IVK, indicating that upgrading is optional rather than mandatory to join the activity). I have found this concept (Interface Version Key) to be remarkably valuable in supporting the maintenance of distributed systems. -- [kritchie]