Cześć Adam :-)
- is it reasonable (thinking about reactive streams in general) to have an actor which produces elements on-demand (instead of providing a collection/iterator/() => as is currently supported)? As far as I understand the current implementation, subscribers explicitly ask publishers for more elements (through Subscription.requestMore) - so it seems it would be possible to pass such a request to an actor and ask for the given amount of elements. Is there any chance to get "actor producers" in some future releases, or there are no such plans currently? Yes, definitely! We currently do support it (on release-2.3-dev, it’s pretty new) via: ``` /** * Define the sequence of elements to be produced by the given closure. * The stream ends normally when evaluation of the closure results in * a [[akka.stream.Stop]] exception being thrown; it ends exceptionally * when any other exception is thrown. */ def apply[T](f: () ⇒ T): Flow[T] ``` Which generates an `Actor` backed producer for you (that will call your function), or if you need complete control you can implement a `Producer[T]` and give it to `Flow`: ``` /** * Construct a transformation of the given producer. The transformation steps * are executed by a series of [[org.reactivestreams.api.Processor]] instances * that mediate the flow of elements downstream and the propagation of * back-pressure upstream. */ def apply[T](producer: Producer[T]): Flow[T] ``` These should be enough to implement what you’re after. Disclaimer Please note that the spec ( https://github.com/reactive-streams/reactive-streams ) is under heavy discussions and development at this moment. Our current impl is still targeting the previous version, differences include for example dropping the Producer interface in favour of only keeping `Publisher` etc. Also known as: This is still is changing a lot :-) - another thing is if the streams are thought to be more local, or remote as well? There's currently the TCP stream implementation, which I guess would indicate remote as well (and in such scenarios the need for backpressure arises quite naturally, maybe even more than in locally), but do you plan to develop this somehow? E.g. when there would be multiple consumers for a single producer, a useful component would be a load-balancer which takes into account the backpressure information. We’re currently focused on in-jvm implementations, though multi-language-and-runtime are definitely on the reactive-streams’ radar: https://github.com/reactive-streams/reactive-streams/issues/45 Let’s first nail the in-vm implementation to then move on to the bigger picture (personal opinion here), but there’s so many people involved and loads of excitement around it, so we’ll see ;-) As for Akka, we’re currently mostly focused on getting akka-http (which will be stream based) out of the door, and optimise it, the rest comes next. I hope this helps! // So... what Producer are you implementing? :-) -- Konrad 'ktoso' Malawski hAkker @ typesafe -- >>>>>>>>>> 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.
