MMLite is built around a number of basic concepts. This page attempts to shed some light on them. See also build.htm for how these play into building the system + specifics.
An interface, also known as an abstract class, defines the interaction between a user of an object (the client) and the implementer of the object (the server). An interface is essentially a list of methods (functions) that the object understands -- and their arguments and behaviors.
An interface is purely abstract in that it is not tied to any particular implementation. In fact the same interface is frequently reused and multiple components implement the same interface, often multiple times.
Interfaces extend other interfaces. The base interface for practically all other interfaces is called IUnknown (the name refers to the fact that to the holder of an IUnknown it is unknown what other interfaces the object implements before asking with QueryInterface, in some other object systems IUnknown is called e.g. Object).
An extended interface has all the methods and properties of the interface that was extended plus any new methods and propertiers.
Known interfaces are authored in XML files (named *if.xml) in the conf directory (look for the <interface> element) and are represented in readable form in interfaces.htm. All the configuration files are included from conf/spec.xml.
Those <component>s that have one or more <namespace> element can be called as SOAP services.
An interface is implemented by a concrete class that in turn resides within a component.
A concrete class implements one or more interfaces. Where an interface is purely abstract, a concrete class is concrete, i.e. it is one particular implementation. A concrete class is part of a component. Instances of objects served by concrete classes are usually simply called objects.
A concrete class can inherit another concrete class (also called subclassing). In that case some methods are copied from the super-class (the one inherited from) and others are implemented by the subclass (the methods override those of the super-class).
The object system (ComLite) implemented in Microsoft Invisible Computing and described in the XML configuration files in src/conf supports only simple inheritance between concrete classes. Multiple inheritance is supported when concrete classes implement multiple interfaces, but this is the only multiple inheritance supported. Multiple inherited classes cannot be inherited (i.e. they cannot be super-classes) and only one concrete class can be inherited from in any one concrete class.
Known classes are authored in XML files included from conf/spec.xml and are often located next to a group of related source directories. Look for the <concrete-class> element.
A component is a collection of concrete classes and some glue code that ties them together. A component typically exports its basic functionality through a factory object that has constructors for other concrete classes of the component.
Components can be assembled in many ways but the COB (Component Object Binary) is particularly well matched. In a COB, the entry point of the executable image (CobMain) returns an object. This object would be the factory object. COBs can also be easily linked into the system by presenting the entry point in a built-in COB table.
The build process usually turns all components into libraries and leaves it to the packaging stage (in conf/package) to assemble them into various configurations. Some can be statically linked, others put into ROM file systems; some in dynamically loadable COBs, EXEs, DLLs; some in the boot image, some in a file system, others on a web server, yet other compiled on demand.
Components may have static dependencies on other components or the dependencies may be dynamic.
Known components are authored in XML files included from conf/spec.xml and are often located next to a group of related source directories. Look for the <component> element.
Source files contain the actual implementations of concrete classes. The existing source files are grouped according to their component and component groups.
Templates for new classes are automatically generated from <component> and <concrete-class> elements. The generated code is put into build/stubs. The generated code is often useful as a staring point for authoring a new component. The stub generator assumes the first <concrete-class> in a <component> is the one to be returned by the component entry point. Typically the returned object is a factory object, useful for creating other objects. Note that the entry point is only called once so it is not useful to try to return more than one instance.
All files are listed here but the structured listing is likely to be more useful.