Commit graph

7 commits

Author SHA1 Message Date
Patrik Nordwall
da5c4c4594 =str #15900 Make fanout publisher actor name unique 2014-09-29 16:05:31 +02:00
Patrik Nordwall
30095e5386 =str FutureSink must not be singleton
* and more careful use of  Source / Sink in Maps
2014-09-11 16:08:16 +02:00
Patrik Nordwall
5b360a76b0 =str Source/Sink vs SourceVertex/SinkVertex equality
* it must be possible to use PublisherSink (object) at several places in the graph
2014-09-11 08:09:28 +02:00
Patrik Nordwall
e3fc05b0f3 =str #15741 Hook-up conflate, expand, buffer, and FoldSink 2014-09-10 08:59:03 +02:00
Patrik Nordwall
400e49e88d =str #15735 Prototype of FlowGraph
Add documentation
2014-09-09 13:19:32 +02:00
Endre Sándor Varga
3a60ed96d1 !str #15604: Removal of default fanout behavior 2014-09-04 15:49:14 +02:00
Roland Kuhn
61b77ea50c =str #15755 #15756 rework Source/Sink materialization
The philosophy is that the FlowMaterializer has complete control over
how it interprets the AST, no restrictions. Therefore it only involves
one specified method: materialize() which returns a MaterializedFlow.
Within the ActorBasedFlowMaterializer we materialize Sources and Sinks
that implement the specified SimpleSource/SourceWithKey interfaces (same
for Sinks), others are not supported. These traits are extensible and
they require that an ActorBasedFlowMaterializer is passed into the
factory methods. Other materializers can of course interpret these AST
nodes differently, or they can use the actor-based facilities by
creating a suitable materializer for them to use.

This means that everything is fully extensible, but the infrastructure
we provide concretely for ourselves is built exactly for that and
nothing more. Overgeneralization would just lead nowhere.

Also made FutureSink isActive and implement it using a light-weight
Subscriber instead of a Flow/Transformer.
2014-09-04 14:05:51 +02:00