+++ /dev/null
-This will be a module to synchronise two Citadel servers.
-
-We should add comments here for features that are needed
-
-
-The initial plan is that this module will provide services to allow
-a new Citadel server to collect all data from an existing Citadel server
-resulting in the new server being a complete duplicate of the original.
-
-All data must be transfered over the wire.
-The data synchronised should include the log in/out messages and anyfiles
-in a room not just the content of the message base.
-
-I think we should structure this as a series of commands that can be issued
-in any order with the exception of one command that forces the exporting
-server to go "single user" to ensure the system doesn't change during the sync.
-
-These are the commands I can think of at the moment.
-
-SNGL Go single user.
-This will prevent new logins from happening and also prevent inbound messages
-from SMTP, IMAP RSS and IGNET etc.
-This command should allow real user to complete what they are doing and should
-probably give them a message to say the system wants to go single user.
-This command should take two arguments. The first is the time to wait for the
-system to go single user. The second argument is the time to expire single user
-mode if the requesting server disappears.
-
-ESNG End single user mode.
-
-SYNC Main command for all synchronisation options.
-This is to be followed by 2 or more arguments.
-Argument 1 is the type of Citadel data to be worked with eg. rooms, files
-messages, users etc.
-Argument 2 is the action to carry out on the specified data.
-
-
-So a sequence might go something like this:
-
-Unconfigured server. Old server
-SNGL 120|500 Goes single user within 120
- seconds. Reverts to normal
- operation if no activity
- for 500 seconds.
-
-SYNC users|info Send back info on the system
- users. A CRC and a few other
- items so that the requesting
- server can determine if its
- user data is out of sync.
-
-SYNC users|getall Send back all users info.
-
-ESNG Revert back to multi user mode.
-
-
-Obviously there is lots to be worked out here. It may be a good idea to
-timestamp every thing to determine the need for updates.
-
-If we do this right this module could replace IGNET and ARTV and could be used
-clients to sync mailboxes and calendars etc.
-
-We should care a bit about performance here.
--> not use the sendcommand/ctdl_ipc here.
-To gain performance, (profiler says...) we musn't read byte by byte aymore, but read blocks.
-thus the out/input format should be a bit similar to the http chunked mode, sending blobs of
-n bytes at once.
-Probably up 64K windows are apropriate here. it could look like that:
-<line by line mode>
-Messageheader=blabla
-AnotherMessageHeader=blub
-DATA CHUNK 65535
-< 64 k BLOB >
-CHUNK 2344
-< 2344 bytes; probably the overlaps of the message. >
-