This makes me sad because wrapping an ask inside of mapAsync seems to fundamentally discard/break two very useful abstractions at the same time. I'd much rather have the ability to have a component of a stream graph that actually knows it's participating in such. This is of course not to mention the fact that having to use an Ask (with all its associated overhead and need for an implicit Timeout) seems to kind of violate every reason to actually be using Akka in the first place.
I'm well aware that this could be implemented with a custom Stage, but that API seems a bit clunky for something that is by nature reactive and asynchronous. Caveat to all of this - I'm well aware that the Typesafe/Akka guys grok this domain on a more fundamental level than I do, so I could be missing something. On the other hand, I am a consumer/user of the platform, and I'd like to think that I'm quite smart and capable. If I can't do it, then maybe the abstraction or API needs some work. > On Apr 22, 2015, at 8:49 PM, [email protected] wrote: > > Have you seen this thread? The authors have stated that custom > ActorProcessors aren't going to be implemented anytime soon, howewer I would > be very happy too if they'd changed their minds =) > >> On Wednesday, April 22, 2015 at 8:23:54 AM UTC+3, dpratt wrote: >> The ActorPublisher and ActorSubscriber are natural (and easy) ways to deal >> with integrating with external or non-streaming APIs. Adding the obvious >> ActorProcessor implementation would also be a pretty big help. Currently the >> Http and StreamTcp modules actually do have an implementation of this, but >> it's marked as an internal only API. >> >> As you can imagine, it would make life a lot easier if we could somehow get >> a Flow[Input, Output] from either a Props for an ActorProcessor or even >> create one from a reactive streams Processor instance. For example, I'm >> currently working on some things that would be drastically simplified if >> there was an easy way to model a Flow[Ack, MessageDelivery] using this >> proposed API. I know it seems a little off, since from a semantic point of >> view, the output IncomingMessage instances aren't created from the incoming >> Ack messages, but the goal here is to use this Flow as the left hand side of >> a stack of BidiFlows. Of course, I could do this today by just implementing >> all of the AMQP protocol from the network framing level up on top of a >> StreamTcp Flow[ByteString, ByteString], but as you can imagine, AMQP is >> complex, I'd really rather just play with my dog, and my employer would >> frown on a monthlong diversion reinventing the wheel when there are already >> decent AMQP JVM implementations out there. >> >> Thoughts? > > -- > >>>>>>>>>> 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 a topic in the Google > Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/__jiYeub9Ew/unsubscribe. > To unsubscribe from this group and all its topics, 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. -- >>>>>>>>>> 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.
