[glib-controller] Update the README

[Emmanuele Bassi <ebassi src gnome org>]

commit 0a61992d63f2b108e5af612b4f39749291f666b5
Author: Emmanuele Bassi <ebassi linux intel com>
Date:   Fri Apr 30 16:17:50 2010 +0100

    Update the README

 README |   40 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 40 insertions(+), 0 deletions(-)
---
diff --git a/README b/README
index 33f666d..b6cdf12 100644
--- a/README
+++ b/README
@@ -1 +1,41 @@
 GController :: A Controller implementation for GLib data types
+===============================================================================
+
+The story so far...
+-------------------------------------------------------------------------------
+Given a model-view-controller design, the current approach in GLib-based
+libraries is to encapsulate the data structure used for storage and add
+storage accessors that notify the view(s) of changes - thus conflating the
+model and the controller sides into one data structure.
+
+Encapsulation of storage and controller has invariably led to some issues:
+
+  â?¢ data replication: unless the model is an interface that resides at a
+    lower level in the dependency chain, and that can be bolted on top of
+    an existing data storage, there has to be a copy from the simple data
+    storage types provided by GLib (GArray, GList, GHashTable, etc.) into
+    the model itself.
+
+  â?¢ data access replication: be the model an interface or a base class,
+    it requires the implementation of an API to access the data from the
+    storage, including iteration over the data storage.
+
+  â?¢ loss of performance/generality: if a model has to be accessible from
+    higher levels of the platform stack, it has to lose every knowledge
+    of data types, or re-implement them abstractly, incurring in a loss
+    of performance; conversely, if it can be placed at higher levels of
+    the stack, it will become tied to the view structure, losing
+    generality.
+
+These issues have been nominally approached by different libraries in
+different ways - but always trying to maintain the model (data storage)
+and the controller angles together.
+
+GController: An alternative angle of attack
+-------------------------------------------------------------------------------
+Instead of collapsing both model and controller inside the same class it
+should be possible to devise a way to use simple data structures already
+provided by GLib for storage, access and iteration, and decouple the
+controller into a separate class.
+
+More information at: http://live.gnome.org/EmmanueleBassi/GController