Hi Andy,

your pipes and filters implementation looks nice, however, it really  
doesn't have that much to do with FilterStreams (though you did  
reuse that name despite pounding me for it earlier, grmph..).

What you are doing is faithfully re-creating UNIX pipes and filters;  
FilterStreams are an application of the pipes and filters  
*architectural pattern* that is purposely different from the UNIX  
model.  It goes beyond it in some respects, and is decidedly simpler  
in others.

It is simpler in that the base-model uses a simple push-only model  
that is sufficient for most uses and makes both the core  
implementation and all subsequent filters simpler.  This doesn't  
restrict generality because buffering and pull-based processing can  
be provided via trivial adaptors (so placing FilterStreams into your  
Pipe presents no problem).

It goes beyond a simple pipe and filter model in that it uses the  
double-dispatching strategy of a Visitor pattern to integrate the  
individual filter-stages with normal Smalltalk messaging.  Each  
concrete filter essentially represents a 'generic' operation such as  
#printOn:,#storeOn: or #fullDrawOn: that involves a traversal, an  
operation and some target or state carrying object.

Like other Visitors, FilterStreams allow reuse of traversal and  
operation code, thereby allowing easy addition of new operations.   
Think of a #debugPrintOn:.

There's quite a bit more I could say.  Maybe if there are specific  
questions...  Did you get my responses to your criticism?  I think I  
addressed your points there.  Anyway, what you're doing is really  
quite different from what I've been doing.

Regards,

Marcel