Hi Tzu-Chiao, great questions although I'd relay those into a seperate discussion. The design proposed does not intent to change the way we provide oberservibility via persisting activation records. The controller takes that responsibility in the design.
It is fair to open a discussion on what our plans for the activation record itself are though, in the future. There is a lot of work going on in that area currently, with Vadim implementing user-facing metrics (which can serve of part of what activation records do) and James implementing different ActivationStores with the intention to eventually moving activation records to the logging system. Another angle here is that both of these solutions drop persistence of the activation result by default, since it is potentially a large blob. Persisting logs into CouchDB doesn't really scale either so there are a couple of LogStores to shift that burden away. What remains is largely a small, bounded record of some metrics per activation. I'll be happy to see a separate proposal + discussion on where we want to take this in the future :) Cheers, Markus
