[mbackup-devel] design flaw.
Status: Alpha
Brought to you by:
jo2y
|
From: James O'K. <jo...@mi...> - 2000-07-11 06:07:27
|
I've starting to become away of a design flaw in the current setup and I need some brainstorming help for a fix. Things have worked fine until now when everything has been flowing from disk through filters and out to disk. Now that I'm trying to integrate restore functionality that simplicity quickly falls apart. For example, the plain_reader.c and plain_writer.c are basically opposites, so I've started to merge them into one filter. The problem comes in when I need to call read_file(), is this a read for backup or for restore? If it's a backup, then currently we read from the config value startpath. It gets harder when we do a restore because there isn't (cuurently) a config value to say where things are stored. All of this could be solved with a rewrite to these modules. The other problem is when there is a network involved. I'm hoping to have just one server program that does restores and backups. Under the current plan, the network module on the server would have to communicate to the main program that we are doing a restore because that calls for a whole different set and order of filters. A third problem is communication between and random module and the indexing module. Since this could be on a remote server, we would prefer to not have every module making their own connection to the server to ask questions. Anyone have any ideas? I've been thinking about this for a few days.. -james |