Warum eine FFI-Grenze architektonisch relevant ist
Native Fachanwendungen können unterschiedliche Sprachen, Frameworks und Releasezyklen verwenden. Eine bewusst kleine C-kompatible Integrationsgrenze kann dabei als sprachneutraler Übergabepunkt dienen, während interne Rust-Typen und Bibliotheksdetails nicht zur öffentlichen Host-Schnittstelle werden.
Für die öffentliche Darstellung ist deshalb die Stabilität des Vertrags wichtiger als eine lange Liste interner Module oder exportierter Symbole.
Warum der Native-Vertrag nicht mit jeder Operation wachsen muss
Der aktuelle Headless-Scope bildet 37/37 Produktoperationen ab, ohne daraus 37 unabhängige Native-Owner oder monolithische Sprachfassaden zu machen. Die zusätzliche 63-Domain-Messenger-Breadth wird hinter derselben begrenzten Produkt-/Capability-Architektur bewertet und erzeugt keinen zweiten Runtime-Owner.
Java, Kotlin und Swift exponieren dafür schmale Capability-Objekte. Das reduziert die Gefahr, dass die Host-Binding-Schicht selbst zum zweiten fachlichen Implementierungsowner wird.
Was ein Integrator konkret wissen muss
- Welche API-/ABI-Version gehört zum freigegebenen Release?
- Welche Daten gehören dem Host und welche Zustände bleiben im Runtime-Kontext?
- Wie werden Fehler, Cancellation, Shutdown und Updatefälle modelliert?
- Welche Zielplattformen und Bindings wurden für den konkreten Release geprüft?