Thx a lot for the amazing work
Already used by beta feature at Clever Cloud ;-)
Best Regards,
Le vendredi 27 février 2015 17:08:24 UTC+1, rkuhn a écrit :
>
> Dear hakkers,
>
> we are pleased to announce the availability of the fourth milestone of
> Akka Streams & HTTP. The biggest directly visible feature of this release
> is a completely new and fluent Java DSL for writing FlowGraphs:
>
>
> 1. final RunnableFlow<Future<List<String>>> result = FlowGraph.factory
> ()
> 2. .closed(
> 3. Sink.<List<String>> head(),
> 4. (builder, out) -> {
> 5. final UniformFanOutShape<Integer, Integer> bcast = builder.graph(
> Broadcast.create(2));
> 6. final UniformFanInShape<Integer, Integer> merge = builder.graph(
> Merge.create(2));
> 7.
> 8. builder.from(in).via(f1).via(bcast).via(f2).via(merge).via(f3.
> grouped(1000)).to(out);
> 9. builder.from(bcast).via(f4).to(merge);
> 10. });
>
>
> The biggest internal change shines through this sample as well: the type
> returned from the FlowGraph factory describes the result of its
> materialization. In this example we import Sink.head() into the graph as
> an argument to the factory method, which will propagate the materialized
> value to the overall graph—materializing and thereby running this graph
> will return the Future that the head-Sink materializes to. In order to wire
> this sink up to the rest of the graph, its so-called “shape” (called “out”
> above) is passed into the block that constructs the graph.
>
> Another thing to notice is that we explicitly import the Merge and
> Broadcast junctions into the graph, yielding UniformFanInShape and
> UniformFanOutShape, respectively. This demonstrates that our Graph type is
> no longer “untyped”, every graph now has a Shape. A Source[T, M] is just a
> Graph[SourceShape[T], M], which means that it has a shape that has a single
> output and materializes to a value of type M. Please take a look at the
> freshly rewritten documentation
> <http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4> to see
> this all in action.
>
> You might be wondering why we did such a big change to the already quite
> good DSL, in particular one which will break a lot of source code (sorry
> guys and gals, but you knew what you signed up for when using pre-alpha
> software in your projects, right? ;-) ). The reason is a deep and
> foundational one. The central promise and design goal of Akka Streams is
> “supreme compositionality”, we have been calling stream elements
> “blueprints that can be freely reused”. When trying to implement these
> semantics, we discovered that the approach of using the MaterializedMap
> structure was fundamentally flawed: importing for example a Sink twice
> would lead to incorrect results when trying to obtain both materialization
> results, because the user code has only one Key in its hands. The only
> principled solution to this problem is that materialization results must be
> combined explicitly when multiple are generated from the same graph, and
> this principle applies in a hierarchical fashion. For an example see the
> docs for Java
> <http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/java/stream-flows-and-basics.html#Stream_Materialization>
> and Scala
> <http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-flows-and-basics.html#Stream_Materialization>,
>
> here’s an excerpt:
>
>
> 1. import FlowGraph.Implicits._
> 2. val r: RunnableFlow[(Promise[Unit], Cancellable, Future[Int])] =
> 3. FlowGraph.closed(source, flow, sink)((_, _, _)) { implicit builder
> =>
> 4. (src, f, dst) => src ~> f ~> dst
> 5. }
>
>
> The second argument list combines the three values generated by the
> source, flow and sink into a Tuple3 (using Scala’s lambda short-hand
> notation, the Java example would use «(src, f, dst) -> new Triplet(src,
> f, dst)» for a suitably defined Triplet class).
>
> In addition to these fundamental things we have also worked on new
> features:
>
> - configurable supervision strategy for stream processing stages (PR
> <https://github.com/akka/akka/pull/16772>)
> - add ContentEncoding negotiation
> <https://github.com/akka/akka/issues/16593> (thanks André / @2beaucoup
> !)
> - add Referer <https://github.com/akka/akka/issues/16822> header to
> HTTP model
> - make ShortNumber <https://github.com/akka/akka/issues/16814> path
> matcher work and add minimum number to repeat
> <https://github.com/akka/akka/issues/16833> modifier
> - refactor HTTP RejectionHandler
> <https://github.com/akka/akka/issues/16835> to make it more predictable
>
> For a list of all closed issues, see the milestone on github
> <https://github.com/akka/akka/issues?q=is:issue+milestone:streams-1.0-M4+is:closed>
> .
>
> Happy hakking!
>
>
> *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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
