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 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.
