I've been following Akka Streams for bit. I've noticed the changes in M4 and of course read the materialization sections of: http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-flows-and-basics.html
I have tremendous respect for the Akka team and understand that getting this right is hard. But, are we there yet? Originally the concept was Map based, with the ability for stages to set keys within the map and eventually the client had access to this map. Not really type safe, or clear as to what keys were available, or what their types were, etc. So that's not great. But on the flip side (and why I think it was reached for first) it was extensible. Now with M4, we are much more clear and explicit about what materialization each stage offers. This looks a lot better. But I'm worried about what happens when you attempt to evolve these materialization types later, especially for stages provided by the core library. I'm thinking down the road to Monk, where the goal is to provide a nice tracing abstraction and SPI. And if folks are interested in tracing Actors today, with Streams, they'll be interested in tracing materialized flows tomorrow. Given this current mechanism for exposing a per-stage materialization value, how later would we switch all of our Unit materialization values to materialization values that contain "standard metrics"? It isn't there today, but in the future a lot of runtime metrics could be gathered and exposed. With M4, I don't see a clean way of evolving or exposing new "secondary" materialization values over time. "Secondary" is in the eye of the beholder, but we have preferredMerge stages, and things like Try and Option that have success based affinity within flow processing. I can't prescribe a complete solution in this post but I would like to talk this out. Down the road how do we intend to support the exposure of new materialization based information and/or patterns? How would "adaptive flows", flows that adapt to runtime realities, be implemented? How would one get access to a Stream of materialization values of a running Stream? I hope this is food for positive thought and a positive discussion. PS: This particular post uses tracing and metrics as an example, but I think there's a larger fundamental problem to be solved. Should each stage need to evolve from a materialization of Unit -> tuple/wrapper -> new tuple/wrapper. All the while likely breaking backward compatibility in the process. -- >>>>>>>>>> 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.
