[mbackup-devel] design flaw.

[James O'K. <jo...@mi...>]

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