Hallo Hagen,
nach Deinen Schilderungen und dem wenigen, was ich über dieses Thema weiß, würde ich ebenfalls für die zweite Variante, der von (teilweise) gepufferten Streams, stimmen. Das Kaskadieren von Operationen kann dann sehr elegant über Threads nach dem Producer-Consumer-Pattern umgesetzt werden, so dass einerseits die Puffergröße minimiert und andererseits die Übersicht gesteigert werden kann, weil die Synchronisation vollständig transparent innerhalb der Streams gestaltet werden könnte.
Hast Du Dir schon einmal das Stream-Konzept unter Smalltalk oder Java angesehen? Hier wird intensiv vom Decorator-Pattern Gebrauch gemacht und Funktionen wie Pufferung (sinnvoll bei Sockets oder Dateien), Komprimierung (eine "echte" Funktion) und selbstverständlich auch Anbindung an eine Quelle oder eine Senke (Speicher, Dateisystem, StdIn/Out,...) jeweils mit einer Stream-Schnittstelle implementiert (tatsächlich von abstrakter Oberklasse geerbt). Gemäß des Decorator-Patterns aggregieren oder komponieren die einzelnen Streams so andere Exemplare mit identischer Schnittstelle und können gegenseitig ausgetauscht werden (siehe auch GoF). Sogar eine Concatenation von Streams ist so transparent mit einer StreamList erreichbar, die ihrerseits lediglich die einfache Stream-Schnittstelle veröffentlicht und beim Erreichen des Endes des einen mit der Bearbeitung des nächsten fortfährt
Bei der Wahl der Stream-Schnittstelle sollte man Größe der lesbaren Datenblöcke an die Erfordernisse anpassen: Gibt es bei den Algorithmen kleinste Datenworte (zB Byte oder DWord) oder sind auch Operationen auf Bit-Basis denkbar? Werden Streams im Zweifelsfall aufgefüllt?
Ich würde gerne über geeignete Konzepte diskutieren, aber vielleicht sollte das in einem neuen Thread geschehen?