Sidecar connectors
A sidecar connector is a protocol that arrives as a plugin with a process of its own. The TCP connector is the first example; OPC UA and fieldbuses are meant to take the same route.
Why a separate process
Section titled “Why a separate process”A connector needs the opposite of a sandbox: free network access, its own libraries, often Python. So its code does not run inside the program but beside it — one process per plugin. If it crashes, only that connector stops.
The form is there regardless
Section titled “The form is there regardless”What fields a protocol needs is declared as data in the plugin’s manifest, not by the running process. That is deliberate:
- You see the connection form even while the process is down — otherwise you would get a blank page at exactly the moment you want to fix the fault.
- Connections and tags carry the connector’s id in their configuration. What they mean must not depend on some process being alive.
A connector may therefore be purely declarative, with no process of its own at all.
When a protocol appears, and when it goes
Section titled “When a protocol appears, and when it goes”| Event | Consequence |
|---|---|
| plugin installed but switched off | the protocol does not appear in the form |
| plugin switched on | the protocol appears at once, without a restart; once its backend is up, the runtime is started too |
| installation restarted | both come back, from the plugin registry |
| plugin updated | the old runtime is stopped, the new version announces its types again |
| plugin switched off or uninstalled | the protocol leaves the form, the runtime is shut down cleanly |
Existing connections and tags stay stored in every one of these cases. They are simply not served while the plugin is off.
Permissions and traceability
Section titled “Permissions and traceability”- A package that wants to hold a connection of its own must carry
net:socketin its manifest. Without it the connector gets no runtime — and that is named in the log. - Values a plugin connector writes into tags go through the same mediated door as any other plugin access. What counts is what the manifest was granted at install time, and every write leaves an audit entry naming the plugin.
- Whatever arrives on its own at night is recorded as machine, not under the name of the person who last touched the interface.
What the host decides, and what the plugin decides
Section titled “What the host decides, and what the plugin decides”The plugin holds the socket and reports what arrived: “connection X received this telegram.” Which tag that is, TrakState decides from the tag configuration. The plugin knows no tag paths and therefore never has to be kept in step with an edit.
When a type never appears
Section titled “When a type never appears”If a plugin announces a connector type that breaks the rules — an id already taken, an illegal id, an illegal field name — it is refused. The plugin stays switched on, the type simply does not appear, and the reason is in the installation’s log.