Hobby OS projects (by alaric)
CARBON also defines a load of standard logical statement types, defining a core vocabulary to allow interoperability. For a start, it defines statements an entity may make about itself in order to declare its capabilities (in terms of the list of MERCURY interfaces it exports to clients), as well as its descriptive metadata - name, icon, description in various languages, etc.
Also, it defines statements that make up a global naming scheme. Entities may declare that they have named child entities, creating a hierarchial namespace. I plan to run an ARGON cluster that provides a CARBON 'root node entity', whose ID is hardcoded into ARGON setups, so that it provides a global namespace, alongside organisational local namespaces.
The namespace is important elsewhere in the system, since it allows for namespaced symbol names; indeed, logical statement types are defined by their CARBON global name.
The client-side CARBON libraries have special support for merging information from multiple entities. This is necessary because, for example, a 'file manager' window showing all the child entities of an entity will need to consult both the parent entity and each child entity to find out the details of the children. The parent entity is most likely to assign them names and positions in a two-dimensional coordinate space so their icons can be arranged in a window, while the icons themselves are most likely to be provided by the individual child entities. Also, one might want to merge in the recommendations of a third-party review database to decorate each icon with a star rating!
By joining entities together into a global hierarchial namespace, while also managing all read access to data fom within entities, CARBON brings a totally unified data model to ARGON. It's as if the entire global network of public ARGON clusters, plus whatever private information you are granted access to, were a single unified database.
This has far-reaching consequences. For example, all references to published resources such as third-party software libraries, fonts, documents, and so on go through CARBON. The ARGON analogue to installing a bit of software on a cluster is to tell the cluster-wide CARBON configuration to keep an up to date local copy of the entire CARBON state of a chosen entity, so that references to the application's code and static data can be serviced without needing network communications beyond the entity itself (although the system may periodically check for new versions, and inform administrators when they appear in order to request permission to update the local copy). An administrator may install an alternative implementation of something by telling the cluster-wide CARBON configuration to fetch a copy of one entity, but use it to satisfy requests for a different name - in effect overriding part of the name space.
The cluster-wide CARBON cache allows administrators to configure clusters so they can survive without an Internet connection. All of the core ARGON OS components are referenced by applications via CARBON, but will almost certainly be explicitly locally cached with manual updates. Please - or else users will overload my servers.
Sun 16th Jul 2006 12:15 am 
Subscribe
By James, Thu 18th Dec 2008 @ 11:13 am
So whens the release? 😛 Wouldn't mind testing this thing with a couple of old forth apps I got kicking around on my drive. -Jim