-
Notifications
You must be signed in to change notification settings - Fork 11
DependencyManagement
see spec of CORBA Component Model (as in M$ implementation, OSKit implementation)
- as long as installable components signature key is trusted, it can be installed without limitations.
- software repositories may provide search-and-install interface, where dependencies are handled automatically.
- in case if signature is not trusted or known, components can still be installed into the sandboxed environment.
ComponentConfigurator framework could be useful for hotswapping and distributing servers (and even the kernel itself).
- Instead of simply "naming" server use a "trader". Naming server is able to locate service by name only, trader can do the same but can also support sets of arbitrary constraints, which is desired when creating configurable distributed systems. (see ANSA trader constraint language, 3.4)
Trader requests:
- identification (TAG=OMOS TAG=Blueprints NAME=FilesystemServer)
- version (6.2)
- flags (LATEST_VERSION, LATEST_COMPATIBLE_VERSION - will return latest version compatible with 6.2 in ABI/API)
wrt CORBA trader - corba is by itself too heavyweight and inflexible to be an agile base for software construction. Better use reality-based simplifications of CORBA architectural concepts, for example KDE's KTrader.
Our reflective ORB is an extension of TAO [25], a CORBA-compliant ORB that optimizes inter-object communication by using different protocols depending on the location of the objects. Calls to co-located servers can be as fast as virtual method calls on a C++ object. The general impression that CORBA was too large and slow corresponds to first-generation brokers. Recent performance measurements [20] suggest that contemporary CORBA implementations are efficient and that even faster implementations will appear.
2K minimal configurable system: http://choices.cs.uiuc.edu/2K not available anymore..
In contrast to existing systems where a large number of unused modules are carried along with the basic system installation, we base the 2K operating system on a “what you need is what you get” (WYNIWYG) model. The system configures itself automatically and loads the minimum set of components required to execute user applications efficiently. The system downloads components from the network and only a small subset of system services is needed to bootstrap a node.
We achieve this by reifying the hardware and software prerequisites for each loadable component. As mentioned earlier, the operating system uses this information to make sure that all the basic services that a component requires are available before the component is loaded. In addition, a distributed resource manager uses the specifications of the component hardware require ments to decide in which machine to load the component and also to perform admission control and resource reservation.
http://choices.cs.uiuc.edu/2K/DynamicConfiguration
Each entity has a network-wide identity, a network-wide profile, and dependencies upon other network entities. When a particular service is instantiated, the entities that constitute that service are assembled.
Metrics for QoS aware management:
- lifetime expectancy - short, long, forever
- latency (LAN/WAN/satellite link etc) - no point to launch short lifetime processes over a high latency link for example.
[25]dynamicTAO
[23]LegORB
Off++
http://choices.cs.illinois.edu Choices sources, search for 2K config system
Clemens Szypersky defines a software component as a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
To provide usability, OS-Kit adopted a subset of COM as the basic framework allowing components to interact with each other efficiently through well-defined interfaces. However, in COM-based systems, components run within an address space with no protection between them.
A unique aspect of MMLite is its focus on support for transparently replacing components while these components are in use (mutation). MMLite uses COM interfaces, which in turn support dynamic reconfigurability on a per-object and per-component basis. However, COM does not provide protection between the components. In MMLite it is not clear if it provides isolation between components or not.
[specomos.ps]
[...] OMOS, a fully programmable linker/loader and persistent server, that fills the roles taken by the linker, loader, shared library support, and exec operating system service in a traditionally structured system[20, 19, 18]. OMOS also provides the means to construct programs that are specialized to their expected operational conditions. This is done in two ways: by inferring operational characteristics from the symbolic names found in modules, or absent from them (implicit disclosure), and by explicit disclosure through annotations. OMOS provides a mechanism to annotate program components, and to examine and respond to those annotations. Through this mechanism OMOS provides a simple way to negotiate an appropriate implementation, without adulterating or complicating module interfaces.
Formal modularity model:
formal model described in the Jigsaw language[1, 2], that provides a basis for relating modularity and inheritance.
[almost all of bibliography needed for reading]
[omos.ps]
Smart linkers discussion on usenet.
Source files building system should be aware of installation as "packages", not just blindly copying files - so an equivalent of "make install" should instead generate a redistributable archive file with all necessary dependencies recorded. This greatly simplifies and majorly unifies the task of package management.
Programs require features by library internal names and a set of feature strings.
Libraries define internal names (name=qtcore, version=4.3.2, major=4, minor=3, build=2) in special internal section .tags, and dyl (dynamic loader) will also update file extended attributes with these values when running on extended attributes-capable filesystem. Libraries feature strings declare features supported by this library build like debug=yes. Dyl will use combination of version and feature strings to find appropriate libraries for the applications.
This makes dynamic linking easier - applications do not have to hardcode paths to used libraries and do not have to rely on specific library names. Your debug Qt4Core library may be in the file Wtf,!ThisDoesn'tReallyWorkToday and still be found by your application properly.
This also helps package management software to resolve dependencies even if the manager can not find appropiately named packages from depends=() specification - it simply scans files inside the package for library specification strings and rebuilds dependency tree.
Package structure allows installing several binary-incompatible libraries alongside each other, so this also helps maintain backwards compatibility over system lifetime. /pkg/stdc-2.1.1 and /pkg/stdc-3.5.7 may peacefully coexist, with corresponding applications finding their appropriate libc versions without even knowing.
libraryname.dl is a common name for dynamic library loaded by dyl server. libraryname.lib is a static library, which is usually linked in by the appropriate linker, but it might be possible to open them at runtime by using the same string feature specifiers and a bit of magic.