Core 2.0

top level wishlist

• typing! Nav type we can check - nav can be a single module or a module graph
• other language support, running as separate binary (py or otherwise)

other (from convo)

• starting stopping modules dynamically (by other modules)
• running modules as separate process (py or cpp)
• module structures should conform to module level specs (like nav can be one module or multiple - and type system needs to understand this)
• no pre-defined INs on modules, only OUTs, modules you depend on you get as an argument (transparently are RPC clients) that you can call rpcs on or .subscribe to topics
• how does this vibe with cpp etc?

class MyModule():
    myimage: Out[Image]
    def __init__(self, robot: ModuleINeed):
      self.robot = robot
    def start():
       # subscribing to robot OUT (no predefined IN)
       self.robot.position.subscribe(...)
      # RPC call 
      self.robot.sit()

Synced from DIM-287 by ivan.dimensional

The issue names no repository files, tests, or entry points; start by mapping the existing module, process, RPC, and type-system architecture. The wishlist needs design decisions before implementation, including module contracts, dynamic lifecycle, language boundaries, and what tests would define completion.