Hi Tim,

this is indeed not a simple question—and thereby also a reason for this
late response—and my current assessment is that we don’t have enough
practical experience to draw a conclusion just yet. Having a working and
useful implementation is a good first step, thanks a lot! But we will have
to experiment with more and possibly completely different options. One
thing that’s on my mind is a combinator like `.via()` that takes a
Flow-factory and sends data through, recovering from failures. The
semantics are not yet self-evident, but such a scheme could be used to
implement reliable processing—we are also lacking persistent stream stages,
though.

On your question about using internal knowledge: it sounds dangerous to
special-case custom fusing etc. since that is the domain of (separate)
Graph optimizers that should work without having to know about these other
things; of course there may be internal APIs that are not yet there or not
properly scoped/exposed, but we need to be extra careful when attacking
those.

Regards,

Roland


On Sun, Aug 9, 2015 at 11:30 PM, Tim Harper <[email protected]> wrote:

> After sleeping on this, and obsessing over the problem, I've come to the
> conclusion that these are the two options for Acknowledging streams:
>
>    - Stay with the Promise based implementation. It's simple, and while
>    it has a few downsides, a special network-boundary BidiFlow could be used
>    which maps Longs to promises
>    - Implement acknowledged streams in the akka namespace, in order to
>    access package-level privates that are otherwise impeding a successful
>    development. (So I can implement custom fusing, have access to the error
>    handler, etc.).
>       - Going this route could be workable. I could make the akka-streams
>       version against which it is built be a part of the package name. Then,
>       after the package matures, we could evaluate merging the functionality 
> into
>       a sub-project of akka.
>
> I'm a little torn. The Promise based solution is very simple, even though
> it is quite impure. It uses public APIs and it works well.
>
> I had an objective for op-rabbit to switch to use BidiFlow
> acknowledgements prior to 1.0.0 release, but given the difficulty I'm
> facing, I'm considering dropping this requirement from my roadmap.
>
> Tim
>
> --
> >>>>>>>>>> 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.
>



-- 
Akka Team
Typesafe - Reactive apps on the JVM
Blog: letitcrash.com
Twitter: @akkateam

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

Reply via email to