Architectural decisions with new CSAF

[podhrmic]

Features to import/discuss:

• [ ] where should the examples live / repo structure
• [ ] separate the scheduler and the communication mechanism.
• [ ] RosMsgs
• [ ] ZMQ
• [ ] Compatibility with external hardware and software processes
• [ ] Native support for C language executables
• [ ] What should be cut/preserved from the image below?

[EthanJamesLew]

Some thoughts here:

What should be cut/preserved from the image below?

Nothing, all those pathways still apply

ZMQ

Nothing is interesting about zmq in and of itself. Having component accessible through networking would be the thing lost and we should regain. I would argue that the original CSAF did that so poorly it's something of a moot point.

update claims about using foreign (non-python) components, maybe provide an example

We had no examples previously, and so all of our previous claims were vague.

Native support for C language executables

I would love to see this

RosMsgs

We should go beyond just RosMsgs and go into full ROS components, launch descriptions, and bags. This oversight was caused by my not learning ROS appreciably before the initial implementation.

[zutshi]

I would re-state the features as requirements instead:

• Compatibility with ROS Components: allowing import and export of components from and to the ROS v2 ecosystem.
• Modular: We should separate the scheduler and the communication mechanism.
• Platform agnostic vs Performance tradeoff
• DevOps style structure: CI/CD

[cslockett]

For Aditya to finalize these decisions