Dear hakkers, it has been over a month, so we figured that another milestone of our Streams & HTTP projects is in order. The Christmas break was a bit longer on the HTTP side (i.e. not so many changes there), so most of the work went into streams:
consistently use the word “failure” instead of “error” in the API (see here <http://www.reactivemanifesto.org/glossary#Failure> for the definitions) rename all materializing actions such that they start with “run” (e.g. “runForeach”) to distinguish them from non-materializing ones rename ActorBasedFlowMaterializer to ActorFlowMaterializer (which now uses ActorFlowMaterializerSettings) make use of DeadLetterSuppression to avoid pointless warning messages, also sanitize failure logging in stream stages to avoid duplicates fix a few issues with StreamTcp concerning connection termination last but certainly not least: translate the Scala reference documentation to Java (cookbook still missing at this point) What next? When starting to work on the integration for our SslTlsStage we encountered some difficulties with the current internal design—in fact this reminded us that we had not yet implemented some of the semantics of reusing flow topology blueprints within larger graphs. This triggered a rewrite of the internal representation of FlowGraph that is currently under way. While doing this we discovered another difficulty related to extracting materialized values (like the local socket address for a server binding, or a completion future for a Sink) when reusing the same blueprint multiple times within a larger graph, and the solution for this needs an API change: version 1.0-M4 (to be released in two weeks time) will introduce one more type parameter for all graph elements that materialize to a value, namely the type of that value. Composition operators and graph constructors (like Source(), FlowGraph() and Sink()) will require explicit functions that describe how these materialized values are composed, and overall materialization of a RunnableFlow will then yield only the overall (composed) value instead of a MaterializedMap. This should be safer and more intuitive to use than what we have currently. After this change we plan on keeping the API stable (with the caveat that future enlightenment might reveal flaws yet unknown). On the HTTP front the next task is to start the implementation of WebSockets, and once TLS is available on the Streams layer we will hook that up into HTTP as well. All your feedback (on this list and on github) has been very helpful in pushing Akka Streams & HTTP forward, please stay awesome :-) Regards, Dr. Roland Kuhn Akka Tech Lead Typesafe <http://typesafe.com/> – Reactive apps on the JVM. twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
