>> Thoughts on package handling in capability based systems

There are may reasons why current software systems are not sufficient reliable. A crucial factor is software integrity:

Todays applications are build from multiple software modules, libraries or what ever you call them. Each time a new software package gets installed, there are new or updated modules available. Usually updated modules simply replace the old ones -- all applications former using the old version are now forced to use the new one. This often leads to reliability problems.

I think applications should stay unaffected using their old version until someone explicit updates them to use the new one. Of course "updateing" (relinking a application to other subsystems) should be fast and always possible without the need to insert the installation media.

Talking about capability based systems like EROS, which naturally don't have a global namespace where all software gets installed, there seems to be a obvious way to impement this:

Let there be a service which handles all the required dependency resolution, builds factories on request and links them as requested by the user. This service may not expose write access to packages or factories used by other factories. In fact it should never expose factory capabilities which allow much more than "request product" and "are you confined?".

The following diagram shows what the internal state of such SoftwareBank could look like after 4 packages had been installed.

The 4 packeges contained a least the following meta data: When installing package "A", the user will have to be asked to which B factory the A factory should be linked. The diagramm assumes package "A" had been linked two times -- once to "B", once to "B'".

dependency diagram

There's an important concept not shown in the figure: Sub-Softwarebanks.

There should be the possibility to create a read-only version of a software bank. This bank could be used by further software banks to inherit software: an easy way to seperate access to the systems TCB- and application installation space; or to give users the ability to install their own software. ... to be continued ...

Please note:
  1. By package i think of a template for a single class of factories. Generally, a aplication will come with a herd of packages.
    Maybe the terminology needs rethinking :)
  2. I omitted some dependencies: all factories of course depend on their metafactory. But it's not the normal "depends on" relation. Its more a "is running instance of" relation. See issue (4).
  3. Updating
    I think updating linked factories is a really bad idea. The normal update path should be:
    1. install new packages
    2. successive build new factories and link them to the new packages.
    3. if everything worked as expected, delete old factories.
  4. Recinding factories or packages
    is not as trivial as it seems: we cannot know whether there are products running build by the factory.
    Maybe there is a need to implement a running_instances_counter . But this would imply to poke a hole into all factories. brrr
    Rescinding becomes even more interesting if you consider having SubSoftwarebanks.
    I have some ideas ... to be continued ...
  5. Should factories have their own copy of their data segment?
    This is closely releated to issue (4): the question is: should all products die when their factory is rescinded? (I think so)
    Or shall they continue until the package is removed?
  6. Should factories have access to their package meta data?
    Should factories by default be able to answer questions like: "Whats the exact Version Numner?", "Whats your build date?" or "Did anybody sign this software?".
    I think they shouldn't. If its an application factory, theese informations should be made available through other means with support for internationalization etc. If its an "internal" factory used only by other factories, this information should simply not be available. At least not by default.