On Fri, Aug 15, 2014 at 12:39 PM, Evgeniy Ostapenko <sml...@gmail.com> wrote:
> >> >> Everyone has different use-cases, that doesn't mean that everyone should >> have their own APIs. >> >> Ok. But Api can be pluggable. It will be nice to have ability reuse code > when extends api. > > >> It sounds like you are doing something Akka Streams (or Reactive Streams) >> have never intended to solve. Perhaps easier for our to tailor something >> for your use-case. >> >> >> Closed. > >> >> >> >> >> If you need consistency more then performance then you need Consistent* >> version. If you do not need join operations you can choose performance >> version. >> >> >> What if all you get is a non-consistent source? You can't make that >> consistent no matter what you do. >> >> Yes. However if user know how it can be doing he must have ability to set >> this. For example `asConsistent`. >> >> >> That doesn't make sense, either you _can_ turn non-consistent sources >> into consistent ones, and what exists today is not a problem, or you can't, >> and your proposal will not work. >> >> >> When you have data then you choose most applicable data structure. If you > can doing you data consistency and Consistent structure most applicable to > you why you can't do this? > Ok. Closed. > >> >> >> >> >> 2) Add `preserveOrder` flag for Consistent streams. If >> `preserveOrder`==false then you do not need preserve order in `mapFuture`, >> but need in `merge` >> >> >> Why would you need a flag, since reordering changes the observable >> semantics of the stream, shouldn't it be separate API so one cannot just >> flip a boolean flag but one needs to design for reordering? >> >> Only user define semantic of the stream and if user set >> `preserveOrder`=false then when reordering happens it will not change >> stream semantic. In contrast if `preserveOrder`=true order must will be >> preserve until user do not apply something like `asNonConsistent`. >> >> >> Of course it will change stream semantics. What if "Died" comes before >> "Born"? >> >> If user knows that it can't be happens (or does not matter) then stream > semantic will not changed. > If creation happens AFTER destruction, it is semantically invalid. Your proposal to tweak this outside of the semantics of the flow seems dubious. > > >> >> >> >> >> >> 3) may be add `sortBy` operation >> >> >> To what, and how? How does one sort an unbounded stream? >> >> With time window OverflowStrategy may be. It is only for got ordered >> stream in user defined time window or may be other bounds. >> How you sort unbounded stream inside mapFuture? >> >> >> The naïve solution would just refrain from asking for more elements until >> the current Future completes. No sorting needed. >> >> >> It is a lock. Sometimes it is useful, sometimes it worst. > > -- > >>>>>>>>>> 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. > -- Cheers, √ -- >>>>>>>>>> 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.
