[README] Update to match reality a little closer.

README

@@ -2,8 +2,8 @@ What is applauncherd?
 ==============================
 
 Applauncherd is a daemon that helps to launch applications faster by
-preloading dynamically linked libraries and caching stuff (MComponentCache). It also saves memory, because all launched
+preloading dynamically linked libraries and caching stuff.
-applications share certain resources.
+It also saves memory, because all launched applications share certain resources.
 
 Applauncherd also provides support for fast single instance launches.
 
@@ -23,17 +23,15 @@ Building
 Technical overview
 ==============================
 
-The applauncherd daemon is started by UpStart as part of XSession, that
+Booster daemons (written using the provided library) are started as part of the
-is, at the same level as the desktop (MeeGo Touch homescreen).
+user session. The booster is responsible for forking the will-be-application
-Applauncherd forks the will-be-application process, "booster", before
+before knowing which application is going to be launched next. There can be
-knowing which application is going to be launched next. There can be
 different kinds of boosters optimized for different kinds of
 applications, e.g. Qt or QML.
 
-In the current architecture boosters are loaded as plugins. Applauncherd
+In the current architecture boosters are implemented as seperate processes,
-searches for plugin libraries in /usr/lib/applaucherd/lib*booster.so and
+using the provided support library. Each booster process waits for launch
-forks a new process for each booster to wait for launch commands from the
+commands.
-user.
 
 The user uses the launcher always through a special invoker program. The
 invoker (/usr/bin/invoker) tells booster process to load an application
@@ -47,22 +45,13 @@ In that case exec() is used.
 Technical details
 ==============================
 
-Before loading, booster process changes its security credentials so that
+Loading the binary is done with dlopen(), and therefore the
-the code in the application binary will be executed with the correct credentials. Loading the binary is done with dlopen(), and therefore the
 application needs to be compiled and linked as a shared library or a
 position independent executable. The booster process also sets the
 environment variables. Finally, it finds the main function in the
 application binary with dlsym() and calls the main() with the command
 line arguments given by the invoker.
 
-The launcher itself is a library that is loaded by a small C-program (/usr/bin/applauncherd.bin). Idea behind this is to avoid linking the
-launcher binary to any libraries. This allows us to fully control how
-(with which flags) the preloaded libraries are opened with dlopen(). 
-
-Each application type (currently Qt or QtDeclarative) has its own booster
-process. When booster launches the application by calling the "main()"
-function, applauncherd will create new booster process of that type.
-
 Booster processes do some initializations that cannot be shared among
 other processes and therefore have to be done after forking. This allows,
 for instance, instantiating a application before knowing the
@@ -73,6 +62,12 @@ launched.
 Contributors
 ==============================
 
+People who have contributed to mapplauncherd:
+
+Robin Burchell
+John Brooks
+Thomas Perl
+
 People who have contributed to meegotouch-applauncherd:
 
 Olli Leppänen