On Friday, May 23, 2014 4:57:32 PM UTC+2, Konrad Malawski wrote: > > 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`: >
Is it in the "spirit" of akka-stream/reactive streams to implement your own producers? Or should all producers (publishers) be created by the framework? > *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. > Ah, good to know, I was trying to understand today what is exactly the difference between Producer and Publisher and why do you need that distinction ;) > - 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<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Freactive-streams%2Freactive-streams%2Fissues%2F45&sa=D&sntz=1&usg=AFQjCNEPPvBVRxCWoDYTDt7ggdEt1ljBbA> > 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 ;-) > Sure, it's good to focus on one goal initially, thought the initial akka-streams does contain TCP based streams, which is an open invitation to use it ;) > 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. > stream-based as in reactive-stream-based? > I hope this helps! > // So... what Producer are you implementing? :-) > Just playing around ... to rule the world, as always ;) Adam -- >>>>>>>>>> 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.
