[maemo-commits] [maemo-commits] r16918 - projects/haf/doc/mvo

[From: subversion at stage.maemo.org]

Author: marivoll
Date: 2008-12-09 19:51:59 +0200 (Tue, 09 Dec 2008)
New Revision: 16918

Modified:
   projects/haf/doc/mvo/system-model-2.txt
Log:
Fixos.


Modified: projects/haf/doc/mvo/system-model-2.txt
===================================================================
--- projects/haf/doc/mvo/system-model-2.txt	2008-12-09 17:50:52 UTC (rev 16917)
+++ projects/haf/doc/mvo/system-model-2.txt	2008-12-09 17:51:59 UTC (rev 16918)
@@ -56,8 +56,7 @@
 
 Maemo contains its documentation: reference documentation that is
 generated from source code, introductions and other navigational aids
-to find the reference documentation, example programs, free standing
-texts such as tutorials, internal design documents, etc.
+to find the reference documentation, example programs, tutorials, etc.
 
 Maemo contains applications, plugins, theme graphics and other
 optional add-ons that run on the Maemo OS or enhance it.  Add-ons like
@@ -83,14 +82,9 @@
 still from a safe distance.
 
 There are two important aspects of the Maemo system: the structure of
-its components and the support for developing it.
+its pieces and the support for developing them.  These two aspects are
+called the "System Architecture" and the "Archive".
 
-These two aspects are called the "System Architecture" (the animal)
-and the "Archive" (its habitat).  The Maemo animal could be cared for
-inside the existing and well maintained Debian habitat, but Maemo's
-lifecycle is probably too different from Debian's for this.  Thus we
-have a dedicated Maemo archive.
-
 Architecture and archive are connected by "Packages".
 
 * Packages
@@ -111,19 +105,20 @@
 archived into a tarball, or they can be hosted in a version control
 system.
 
-A binary package is one file per architecture following the Debian
-policy for binary packages.  The files usually have names of the form
-"package_version_architecture.deb".
+A binary package is one file per machine architecture following the
+Debian policy for binary packages.  The files usually have names of
+the form "package_version_architecture.deb".
 
 Maemo supports multiple machine architectures.  If a binary package is
 machine architecture dependent, its sources are compiled once for each
 architecture.  These separate compilation results are stored in
 separate ".deb" files, but for simplicity, this text still treats them
 as a single binary package.  This means that machine architectures are
-not allowed to drift apart in the archive: every architecture must
-contain the same version of a package, or none at all.
+not allowed to drift apart in the archive: a architecture must contain
+the same version of a package as all other architectures, or none at
+all.
 
-In the following, "package" refers to binary packages.
+In the sequel, "package" refers to binary packages.
 
 A package has a name and a version, both strings.  The name and
 version uniquely identify a package.  If a package with a given name
@@ -171,13 +166,14 @@
 
 [ Need some input from the services discussion here. ]
 
-Interfaces are contracts between components.  However, interfaces are
-only tracked on a subsystem level.  Interfaces that are internal to a
-subsystem are managed in whatever way the subsystem maintainers agree
-on.
+Interfaces are contracts between components.  However, only interfaces
+that appear between subsystems are tracked.  Interfaces that are
+internal to a subsystem are managed in whatever way the subsystem
+maintainers agree on.
 
-Interfaces have a name, but no version.  They are formally tracked in
-the Maemo archive (somehow) and available to tools.
+Interfaces have a name, but no version.  They are tracked in the Maemo
+archive as part of the System Architecture documentation and
+information about them is machine readable and available to tools.
 
 [ Versioning interfaces is ultimately not enough.  The evolution of an
   interface can be time stamped with versions, but these time stamps
@@ -206,10 +202,6 @@
 the food chain and we can talk about one subsystem depending on
 another.
 
-Not all clients of a interface depend on the providers of that
-interface.  When there is no provider, the client might have reduced
-functionality, but could otherwise work just fine.
-
 There are different kinds of interfaces, which are explained in more
 detail below: package interfaces, virtual package interfaces, D-Bus
 interfaces, file-based configuration modification interfaces, and