databaselayout.md: updated to remove networking

diff --git a/citadel/docs/databaselayout.md b/citadel/docs/databaselayout.md
index c3198833127c372efd5499e47bd420a514c89433..205fb829c4a6ed4c66a9757739e8ecdbfc62bcd9 100644 (file)
--- a/citadel/docs/databaselayout.md
+++ b/citadel/docs/databaselayout.md
@@ -188,6 +188,10 @@ record, among other things, a reference count for each message.  Since a
 message may exist in more than one room, it's important to keep this reference
 count up to date, and to delete the message from disk when the reference count
 reaches zero.
+
+NoSQL pros might recognize the message store as a "document database".  Each
+record is an arbitrary collection of keys and values, some of which may
+appear all the time, and some which might appear infrequently.
  
 # Here's the format for the message itself:
 
@@ -265,9 +269,9 @@ reaches zero.
     |       |                   |      |                |  Optional, and only in Mail messages.
     | %     |    eHeaderOnly    | nhdr | oNlyHeader     |  we will just be sending headers. for the Wire protocol only.
     | %     |    eFormatType    | type | type           |  type of citadel message: (Wire protocol only)
-    |       |                   |      |                |     FMT\_CITADEL     0   Citadel vari-format (proprietary) 
-    |       |                   |      |                |     FMT\_FIXED       1   Fixed format (proprietary)
-    |       |                   |      |                |     FMT\_RFC822      4   Standard (headers are in M field)
+    |       |                   |      |                |     FMT_CITADEL     0   Citadel vari-format (proprietary) 
+    |       |                   |      |                |     FMT_FIXED       1   Fixed format (proprietary)
+    |       |                   |      |                |     FMT_RFC822      4   Standard (headers are in M field)
     | %     |    eMessagePart   | part | emessagePart   |  eMessagePart is the id of this part in the mime hierachy
     | %     |   eSubFolder     | suff | eSubFolder     |  descend into a mime sub container
     | %     |   ePevious       | pref | ePevious       |  exit a mime sub container
@@ -328,50 +332,6 @@ the *EUID* of the message to the *UUID* of the *vCard* or *iCalendar* item.
 Therefore when you save an updated version of an address book entry or
 a calendar item, the old one is automatically deleted.
 
-NETWORKING (REPLICATION)
-------------------------
-Citadel nodes network by sharing one or more rooms. Any Citadel node
-can choose to share messages with any other Citadel node, through the sending
-of spool files.  The sending system takes all messages it hasn't sent yet, and
-spools them to the recieving system, which posts them in the rooms.
-
-The *EUID* discussion above is extremely relevant, because *EUID* is carried over
-the network as well, and the replacement rules are followed over the network
-as well.  Therefore, when a message containing an *EUID* is saved in a networked
-room, it replaces any existing message with the same *EUID* *on every node in
-the network*.
-
-Complexities arise primarily from the possibility of densely connected
-networks: one does not wish to accumulate multiple copies of a given
-message, which can easily happen.  Nor does one want to see old messages
-percolating indefinitely through the system.
-
-This problem is handled by keeping track of the path a message has taken over
-the network, like the UseNet news system does.  When a system sends out a
-message, it adds its own name to the bang-path in the *<P>* field of the
-message.  If no path field is present, it generates one.
-   
-With the path present, all the networker has to do to assure that it doesn't
-send another system a message it's already received is check the <P>ath field
-for that system's name somewhere in the bang path.  If it's present, the system
-has already seen the message, so we don't send it.
-
-We also keep a small database, called the "use table," containing the ID's of
-all messages we've seen recently.  If the same message arrives a second or
-subsequent time, we will find its ID in the use table, indicating that we
-already have a copy of that message.  It will therefore be discarded.
-
-The above discussion should make the function of the fields reasonably clear:
-
- o  Travelling messages need to carry original message-id, system of origin,
-    date of origin, author, and path with them, to keep reproduction and
-    cycling under control.
-
-(Uncoincidentally) the format used to transmit messages for networking
-purposes is precisely that used on disk, serialized.  The current
-distribution includes serv_network.c, which is basically a database replicator;
-please see network.txt on its operation and functionality (if any).
-
 PORTABILITY ISSUES
 ------------------
 Citadel is 32/64 bit clean and architecture-independent.  The software is