The following problems represent many of the reasons why the current Buildap part development process is not effective. I think I have read every piece of documentation available about the Buildap project, but I have not seen these liabilities addressed yet. Some have been briefly mentioned, but they have not been dealt with.

As noted by Hovhannes in "VSCB Motivations", "Architecture also is the hardest thing to change in a large system. That is why the architectural faults are the most expensive faults."

I think the logical thing to do at this point in Buildap development is to stop, step back from implementation, and critically examine how Buildap will or will not address the liabilities inherent in its architecture.

This forum could be a good first step in that direction.

Thanks,

-Ed


Here are the four liabilities identified in "PATTERN-ORIENTED SOFTWARE ARCHITECTURE VOLUME 1: A System of Patterns"
Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann
page 68 - 69

1. Sharing state information is expensive or inflexible.
If your processing stages need to share a large amount of global data, applying the Pipes and Filters pattern is either inefficient or does not provide the full
benefits of the pattern.

2. Data transformation overhead.
Using a single data type for all filter
input and output to achieve highest flexibility results in data
conversion overheads. Consider a system that performs numeric
calculations and uses UNIX pipes. Such a system must convert ASCII
characters to real numbers, and vice-versa, within each filter. A
simple filter, such as one that adds two numbers, will spend most of
its processing time doing format conversion.

3. Error handling.
As we explained in step 5 of the Implementation
section, error handling is the Achilles' heel of the Pipes and Filters
pattern. You should at least define a common strategy for error
reporting and use it throughout your system. A concrete error recovery
or error-handling strategy depends on the task you need to
solve. If your intended pipeline is used in a 'mission-critical' system
and restarting the pipeline or ignoring errors is not possible, you
should consider structuring your system using alternative architectures
such as Layers (3 1).

4.Efficiency gain by parallel processing is often an illusion.
This is for several reasons:

* The cost for transferring data between filters may be relatively high
compared to the cost of the computation carried out by a single
filter. This is especially true for small filter components or pipelines
using network connections.

* Some filters consume all their input before producing any output,
either because the task, such as sorting, requires it or because the
filter is badly coded, for example by not using incremental processing
when the application allows it.

* Context-switching between threads or processes is generally an
expensive operation on a single-processor machine.

* Synchronization of filters via pipes may stop and start filters often,
especially when a pipe has only a small buffer.

Please share your comments on this. As a hint - Buildap is not pipe and filter style.