>
>
> What might makes sense though is to provide additional, optional settings
> to the materializer that controls how to deal with errors in
> transformations -- similar to a SupervisorStrategy. I am not sure that it
> is possible to meaningfully implement it for all operations though. For
> transformations implemented in terms of Transformer it is very easy, but
> not for others.
>
> Anyway, that would need a careful design round, so it will take some time
> to come up with something that works well and sufficiently general.
>
I think it is native stream's property, not materializer. Materializer is
something like technical config and has no business property. And of course
will you handle exception or not it is business property.
>
> Yes, streams are not globally ordered since it is impossible to
> reestablish global ordering without domain knowledge (i.e. Akka cannot
> figure out what the user code does and how different streams relate -- for
> example two TCP connections carrying video frame data, one carries overlay
> that should be appended at certain timepoints, etc.). We will provide more
> tools to handle that, but we cannot bake it into the low-level model.
>
Very good example! Of course, Akka cannot knows about domain logic. In that
case user must use something like
baseFlow.mergeWithOrder(overlayFlow)(implicit ordering: Ordering[Out]) or
.merge(overlayFlow).sort(implicit ordering: Ordering[Out])
If you need .zip then you need also .consistentZip(overlayFlow)(implicit
comparator: Comparator[Out]).
In both cases Ordering[Out] and Comparator[Out] is properties of Set[Out]
and can be explicitly sets during creation of Producer[Out] (instead apply
them each time when you need .merge and .zip).
If you have two flow which has one initial producer and want .merge or .zip
them, then of course Akka can knows how merge them.
Thank you very much for you answer - it is really helpful.
Now I will try clarify my opinion:
1) Stream is representation of set of elements, which have set of
properties:
a) graph of transformations
b) drop elements with exceptions or not - it can be based on Continuity
Set[Out] or not.
c) all properties of set from Set or Group theory. It can be semigroup,
monoid.. and so on.
2) All properties above is important if you want works with it good.
3) Based on properties of stream you decide how .merge or .zip them and how
propagate exceptions. You can do this automatically.
4) I think best choice is create class StreamSettings() and propagate them
everywhere we need it.
Thank you again, good work!
--
>>>>>>>>>> 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.
