[rygel] docs: librygel-server: More explanation of media-export

[Murray Cumming <murrayc src gnome org>]

commit 68e5d70afa61c349576343520b18f84d29d4c666
Author: Murray Cumming <murrayc murrayc com>
Date:   Tue Jan 22 15:52:16 2013 +0100

    docs: librygel-server: More explanation of media-export

 .../gtkdoc/implementing-server-plugins.xml         |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)
---
diff --git a/doc/reference/librygel-server/gtkdoc/implementing-server-plugins.xml b/doc/reference/librygel-server/gtkdoc/implementing-server-plugins.xml
index d338423..7a6558a 100644
--- a/doc/reference/librygel-server/gtkdoc/implementing-server-plugins.xml
+++ b/doc/reference/librygel-server/gtkdoc/implementing-server-plugins.xml
@@ -71,7 +71,17 @@ implemented in Vala.
 
 <para>The <classname>RygelMediaExportPlugin</classname> class, derived from <link linkend="RygelMediaServerPlugin">RygelMediaServerPlugin</link>, simply instantiates its <classname>RygelMediaExportRootContainer</classname> class, derived from <link linkend="RygelMediaContainer">RygelMediaContainer</link>, providing it to the base class as the root container.</para>
 
-<para>The <classname>RygelMediaExportRootContainer</classname> creates an instance of a RygelMediaExportMediaCache class and a RygelMediaExportHarvester class. The harvester finds files on the filesystem, and stores them in the media cache, which uses SQLite to keep trak of them.</para>
+<para>The <classname>RygelMediaExportRootContainer</classname> creates an instance of a <classname>RygelMediaExportMediaCache</classname> class and a <classname>RygelMediaExportHarvester</classname> class. The harvester finds files on the filesystem, and stores them in the media cache, which uses SQLite to keep trak of them.</para>
+
+<para><classname>RygelMediaExportRootContainer</classname> informs the media cache that it should have a child container for the media content as organised on the filesystem, and additionally some virtual folders for Music, Pictures, Video and Playlists, with further sub-divisions under these, for instance by publication year. These containers are added to the media cache via instances of the <classname>RygelMediaExportNullContainer</classname> class, but that is just to simplify the media cache API and these instances then serve no further purpose. The virtual folders are re-added whenever the filesystem's container is updated, so that they can show the updated 
+content, though that is not particularly efficient.</para>
+
+<para><classname>RygelMediaExportRootContainer</classname> then delegates its <classname>RygelMediaContainer</classname> virtual function implementations to this media cache, which in turn uses the <classname>RygelMediaExportObjectFactory</classname> to instantiate new containers for each request based on their ID. For instance, it returns a <classname>RygelMediaExportDBContainer</classname> if the requested ID indicates a virtual container, using the definition in the rest of the ID to build a suitable SQL query.</para>
+
+<para>The root container derives from <classname>TrackableDbContainer</classname>, which in turn implements the <link linkend="RygelTrackableContainer">RygelTrackableContainer</link> interface, to implement the change tracking profile of the UPnP ContentDirectory:3 specification. Therefore, whenever the root container, or its child items, have changed, we call the <function>rygel_trackable_container_updated()</function>.</para>
+
+<para>Any filesystem folders are implemented as UPnP containers via the <classname>WritableDbContainer</classname> class, which implements the <link linkend="RygelWritableContainer">RygelWritableContainer</link> interface to allow new files to be uploaded to the filesystem via UPnP.</para>
+
 <!-- TODO: Simplify the class hierarchy in the example. -->
 
 </section>