Thanks for chiming in, Jon. > [..] i.e. treat the use of CAF an implementation detail.
This is the clean way to think about layering and creating abstractions. It applies to the API perspective, though. As long as CAF internals are hidden from a Broker user, we are good. The "implementation detail" maxim lead to artifacts like PIMPL. This certainly made sense at the time where we considered multiple messaging backends. At this point, we are invested into CAF, and I don't think switching will happen anytime soon. Therefore, I don't think we need to keep up the implementation-hiding abstractions, such as PIMPL, which come at the cost of development productivity and performance (they are essentially a compiler firewall due to type erasure). Moving forward, I plan to remove the PIMPL design while keeping CAF hidden from the Broker API, but we'll see more CAF code in Broker headers. That's fine in my thinking, because anyone developing and compiling a Broker application must have CAF installed anyway. > At the time, the risk of a copied version getting outdated seemed a > lower priority to me than keeping Broker’s interface/design more > simple/coherent in my head. And to be clear: that rationale totally makes sense in this context and at the time of writing. Matthias _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev