@zhouwei008 I’ll address the three questions you asked here:
- Runtime shape — the app exposes an MCP stdio/socket tool surface rather than an HTTP UI. Does the Application Description care about the interface, or purely about container + config + lifecycle?
At this point, specifying how applications communicate with each other is not in Margo’s scope. There has been some discussion about this, so maybe in the future Margo might have an opinion, but not right now.
So as far as using stdio/socker, Margo doesn’t have an opinion. I think socket-based communication would be the easiest to use since it only requires opening the port in the container. Stdio would be more difficult and would require some special deployment approach to make this work (e.g., sidecars).
- Profiles / variants — I’ve modeled the editions as one application with a
profileparameter (SelectValidationSchema →IAIOPS_MCPenv var). Is that the intended idiom, or would you expect N app packages (one per profile)?
Margo doesn’t have an opinion on how applications are implemented. If having a profile parameter to allow the person installing the application to make a choice makes sense, that is an implementation choice the supplier can make. If it makes more business sense to have multiple application packages, or multiple deployment profiles in the application description, that would be a choice the implementer can make.
- Secret + least-privilege —
v1-alpha1seems to have no secret-typed parameter; how should a workload declare a secret param, plus “read-first, outbound-only to configured OT endpoints, no inbound”? Governance is core to this app.
Currently, handling secret parameters is not incorporated in the specification. We do have an existing feature for adding support for this.