Re:[mbackup-devel] Process block diagram

[Brent B. P. <po...@b2...>]

>>>>> "James" == James O'Kane <jo...@mi...> writes:

On further reflection, I snipped the whole message.

You're apparently thinking of Module's as objects, which seems
fine. You're still going to need (IMHO, of course), sockets in between
particular modules. Named pipes aren't excessively portable, but
sockets are (with the odd exception of Win32 and Win95, but a number
of portability layers between winsocks and sockets exist).

I'm not convinced by the idea of the MCM as CEO, or the rest of the
analogy. At this stage of a project, the most important thing is to
develop a definite, shared vocabulary, and another analogy won't do
that.

Suppose that the MCM constructor takes as input a 'list'. This list
may be supplied either as a file name (in which case it looks much
like a standard unix config file, or not, depending on content) or as
a handle, to be read until closed, or as the name of an external
process, to be executed and read (from stdout of the process) until
finished. In either of the latter cases, the sum of the output will be
identical to the former (in other words, where a manager expects a
file name, it can be handed a file handle or an external process (such
as the name of a perl or python script, or an executable, or
whathaveyou) that can be executed. I hope that that's clearer than the
way I phrased it before. I personally would try to have in mind that
all of the module 

OK, so what does this thing look like? Well, that depends on what the
underlying modules look like, and on what the flow of an archive
section looks like. And there's a problem. Maybe you can sketch out
the dataflow (as a strawman) of a standard archive operation? Say, an
incremental file-by-file backup operation would be a good start.