Log Message:
-----------
Discussion of added diagram

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        plainpaths.sgml (r1.4 -> r1.5)

-------------- next part --------------
Index: plainpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/plainpaths.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/plainpaths.sgml -Ldoc/adminguide/plainpaths.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/plainpaths.sgml
+++ doc/adminguide/plainpaths.sgml
@@ -42,6 +42,56 @@
 the issue where nodes may not be able to all talk to one another via a
 uniform set of network addresses.</para>
 
+<para> Consider the attached diagram, which describes a set of six
+nodes
+
+<inlinemediaobject> <imageobject> <imagedata fileref="complexenv.png">
+</imageobject> <textobject> <phrase> Symmetric Multisites </phrase>
+</textobject> </inlinemediaobject></para>
+
+<itemizedlist>
+
+<listitem><para> DB1 and DB2 are databases residing in a secure
+<quote>database layer,</quote> firewalled against outside access
+except from specifically controlled locations.
+
+<para> Let's suppose that DB1 is the origin node for the replication
+system.
+
+<listitem><para> DB3 resides in a <quote>DMZ</quote> at the same site;
+it is intended to be used as a &slony1; <quote>provider</quote> for
+remote locations.
+<listitem><para> DB4 is a counterpart to DB3 in a <quote>DMZ</quote>
+at a secondary/failover site.  Its job, in the present configuration,
+is to <quote>feed</quote> servers in the secure database layers at the
+secondary site.
+<listitem><para> DB5 and and DB6 are counterparts to DB1 and DB2, but
+are, at present, configured as subscribers.
+
+<para> Supposing disaster were to strike at the <quote>primary</quote>
+site, the secondary site would be well-equipped to take over servicing
+the applications that use this data.
+
+<para> Managers paying bills are likely to be reluctant to let the
+machines at the secondary site merely be <quote>backups;</quote> they
+would doubtless prefer for them to be useful, and that can certainly
+be the case.  If the primary site is being used for
+<quote>transactional activities,</quote> the replicas at the secondary
+site may be used for running time-oriented reports that are allowed to
+be a little bit behind.
+
+<listitem><para> The symmetry of the configuration means that if you
+had <emphasis>two</emphasis> transactional applications needing
+protection from failure, it would be straightforward to have
+additional replication sets so that each site is normally
+<quote>primary</quote> for one application, and where destruction of
+one site could be addressed by consolidating services at the remaining
+site.
+
+</itemizedlist>
+
+<para> 
+
 <para> There is also room for discussion of SSH tunnelling here...</para>
 
 </sect1>