Tag lists more generally appears all over AmigaOS as well - especially as they started running into limitations with the existing APIs that depended heavily on fixed structs with AmigaOS 2.0, they more and more opted for adding taglist parameters to avoid running into the same situation again.<p>And while it&#x27;s request-response based over message ports, personally I see AREXX ports in most larger Amiga applications as a good example of the overall approach of cooperating processes to build larger systems.<p>Dbus and similar systems today has lots of great functionality, but what they miss is what ensured AREXX was &quot;everywhere&quot;: It was trivially simple to support.<p>Pointing to the simplicity of OSC in the article really resonated with me, because a lot of these systems are far less useful than they could be because it&#x27;s extra work. Simple systems on the other hand end up shaping application structure:<p>AmigaOS was massively message based from the outset: Message ports and messages were &quot;built in&quot; and used all over the place. E.g. when communicating with filesystems or drivers or the GUI you do it via messages.<p>Then came AREXX and there was suddenly a standard message format for RPC - both application-to-application and user-to-application.<p>If Amiga-applications were message oriented before, a lot of &quot;post-AREXX&quot; Amiga applications took it to the next level by being shaped around a dispatch loop that included not only e.g. GUI updates, but defining internal APIs that exposed pretty much every higher level action in the application, and used that as an explicit implementation strategy.