Using the GenericHub with updated com patterns

[ReggieMarr]

Hi all, I had previously looked into the GenericHub as a means for distributing data across a system I've been working on. It seemed pretty straight forward at the time however now I'm coming back to it with software targets that are built post v4.0 I wonder if it should really be used in the same manner as before.

Especially in light of all the development promoting the FrameAccumulator, the com adapter pattern, refining the bytedrivermodel and introducing sub-topologies more widely it seems as though that would drive changes to this pattern or at least changes to the reference deployment incorporating the FrameAccumulator and ComQueue.

I'm curious if there are others who are using the GenericHub pattern alongside these other developments so let me know if you are !

[drpnsystems]

Using the GenericHub with updated communication patterns feels like upgrading from a messy group chat to a well-organized team workspace. In the past, connecting systems often meant dealing with clunky, one-to-one links that broke whenever something changed. With newer patterns, GenericHub works more like a smart coordinator — services can “talk” to it in cleaner, faster ways, whether through events, async messages, or lightweight APIs. For developers, that means less time fixing broken connections and more time building actual features. It takes away the frustration of managing endless integrations and turns the hub into a reliable partner that just makes things work smoothly in the background.

[LeStarch]

@ReggieMarr the GenericHub pattern is still useful. However, it lacks one thing for being "easy". Subtopology templaes/instances. Once we have that, instantiating the communications piece under the hub will be easy. We are working this.