From 41dc538e9ab2e8e899ea238ff929d7c72efb1832 Mon Sep 17 00:00:00 2001 From: Aaron Stainback Date: Sat, 18 Apr 2026 22:21:29 -0400 Subject: [PATCH] =?UTF-8?q?round=2033:=20VISION=20v6=20=E2=80=94=20pluggab?= =?UTF-8?q?le=20wire-protocol=20layer=20(PG=20+=20MySQL=20+=20Zeta-native)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Aaron's fifth pass of vision edits generalises the wire- protocol story from "we emulate PostgreSQL" to "protocol layer is pluggable; plugins emulate existing protocols + one for our own native protocol designed for Zeta's features." Aaron round 33: "can we make the wire protocol pluggable and we could just support mysql too to make sure we can support [multiple] and have our own variant so we can start getting support for UIs with our protocol which will be much better." ## Three initial protocol plugins - **PostgreSQL plugin** — pgAdmin, DBeaver, psql, Npgsql- via-EF. - **MySQL plugin** — MySQL Workbench, Connector/NET, Pomelo-via-EF, Azure Data Studio. Second plugin proves the abstraction isn't PostgreSQL-shaped by accident. - **Zeta-native plugin** — our own protocol designed around retraction-native deltas, bitemporal queries, stored- procedure-as-durable-Rx semantics. Future UIs that speak it get first-class Zeta features (time-travel slider, delta streaming, Rx inspection) that emulated protocols can't express. Specification work feeds the eventual Zeta admin UI. ## Why pluggable matters - "Emulate PostgreSQL" as a design assumption leaked into everywhere the wire code touched. Decoupling into "query IR + protocol plugin" leaves the query surface clean. - Second plugin (MySQL) hits early so the abstraction doesn't accidentally bake in PostgreSQL quirks. - Third plugin (Zeta-native) lets us ship features that wouldn't fit in Postgres / MySQL protocol shapes without losing compatibility. ## VISION.md + BACKLOG.md VISION's SQL-frontend v1 list updated: "pluggable wire- protocol layer" replaces "PostgreSQL wire-protocol server," with the three plugins enumerated and Zeta's embedded-library-plus-wire-server shape preserved (in-process F# surface AND wire endpoints can run simultaneously). BACKLOG's wire-protocol entry expanded with the plugin abstraction, precedents (CockroachDB/Materialize/ YugabyteDB/AGE for PG; MySQL Workbench ecosystem for MySQL), and the output-doc sequence (abstraction design first, then per-plugin). Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/BACKLOG.md | 41 ++++++++++++++++++++++++++++------------- docs/VISION.md | 45 ++++++++++++++++++++++++++++++++------------- 2 files changed, 60 insertions(+), 26 deletions(-) diff --git a/docs/BACKLOG.md b/docs/BACKLOG.md index 319637b3..22c9eda2 100644 --- a/docs/BACKLOG.md +++ b/docs/BACKLOG.md @@ -137,19 +137,34 @@ within each priority tier. then `openspec/specs/f-dsl-surface/` once shape stabilizes. -- [ ] **PostgreSQL wire protocol server.** Aaron round 33: - "support an existing protocol so existing tools can - connect." pgAdmin, DBeaver, psql, Npgsql (via EF) all - speak PostgreSQL's wire protocol. Zeta would implement - enough of the frontend/backend message protocol (auth, - simple query, extended query, COPY) to appear as a - PostgreSQL server. Material precedent: CockroachDB, - Materialize, YugabyteDB, Apache AGE — all run non- - Postgres engines behind Postgres-shaped endpoints. - v1-or-early-post-v1 depending on design round: needs - auth shape, SSL/TLS, connection pooling posture, - protocol-level error mapping to DBSP Result types. - Output: `docs/research/pg-wire-protocol-design.md`. +- [ ] **Pluggable wire-protocol layer with PostgreSQL + + MySQL + Zeta-native plugins.** Aaron round 33: "can + we make the wire protocol pluggable and we could just + support MySQL too to make sure we can support + [multiple] and have our own variant so we can start + getting support for UIs with our protocol which will + be much better." Design the protocol-plugin + abstraction first; one adapter per protocol (auth, + message encoding, error mapping, connection-state + machine). Initial plugins: + - PostgreSQL plugin: pgAdmin / DBeaver / psql / + Npgsql-via-EF compatibility. Precedent: + CockroachDB, Materialize, YugabyteDB, Apache AGE. + - MySQL plugin: MySQL Workbench / Connector/NET / + Pomelo-via-EF / Azure Data Studio compatibility. + Second plugin proves the abstraction isn't + PostgreSQL-shaped by accident. + - Zeta-native plugin: designed around retraction- + native deltas, bitemporal queries, durable-Rx + stored procedures. Future UIs that speak it get + first-class Zeta features (time-travel slider, + delta streaming, Rx inspection) the emulated + protocols can't express. + + v1-or-early-post-v1 depending on design round + outcome. Output: `docs/research/pluggable-wire- + protocol-design.md` first, then per-plugin design + docs. - [ ] **Own admin UI (far future).** Aaron round 33: "we will need some UI that can connect to it like SSMS or diff --git a/docs/VISION.md b/docs/VISION.md index 4465e3ff..e093f967 100644 --- a/docs/VISION.md +++ b/docs/VISION.md @@ -1,6 +1,6 @@ # Zeta — Long-Term Vision -> **Status:** round 33 v5 after Aaron's fourth pass of edits. +> **Status:** round 33 v6 after Aaron's fifth pass of edits. > Aaron is the source of truth; this document changes freely. > The `product-visionary` role (to be spawned, see > `docs/BACKLOG.md`) will steward it once it exists. @@ -159,18 +159,37 @@ What makes `Zeta.Core 1.0.0` on NuGet: consumers should never hit a "this feature not implemented" wall. Other ORMs (Dapper, NHibernate, LLBLGen) follow the EF Core pattern. -- **PostgreSQL wire protocol server (v1-or-early-post-v1).** - Zeta speaks the PostgreSQL wire protocol so existing - tools (pgAdmin, DBeaver, psql, Npgsql-via-EF) connect - without modification. Aaron: "we will need some UI - that can connect to it like SSMS or PostgreSQL Admin, - so we will have to build our own (which we will - eventually do) support an existing protocol so - existing tools can connect." This is a server mode - on top of the embedded library, not a replacement; - Zeta keeps the in-process F# surface AND exposes a - wire-protocol endpoint. Significant scope — may - slip from v1 to early post-v1 depending on design +- **Pluggable wire-protocol layer (v1-or-early-post-v1).** + Aaron round 33: "can we make the wire protocol pluggable + and we could just support MySQL too to make sure we can + support [multiple] and have our own variant so we can + start getting support for UIs with our protocol which + will be much better." A protocol-plugin abstraction sits + between the query IR and the network: each plugin is a + small adapter that translates one wire format + (frontend/backend message shape, auth, error mapping, + connection state) into Zeta's internal query surface. + Three initial plugins: + - **PostgreSQL plugin** — pgAdmin, DBeaver, psql, + Npgsql-via-EF all connect unmodified. + - **MySQL plugin** — MySQL Workbench, Connector/NET, + Pomelo-via-EF, Azure Data Studio all connect. + Second plugin proves the abstraction isn't + PostgreSQL-shaped by accident. + - **Zeta-native plugin** — our own protocol designed + around retraction-native deltas, bitemporal queries, + stored-procedure-as-durable-Rx semantics. UIs that + support it get first-class Zeta features (time- + travel slider, delta streaming, Rx stored-proc + inspection) that PostgreSQL/MySQL protocols can't + express. Specification work feeds the eventual + Zeta admin UI. + + The protocol layer is a server mode on top of the + embedded library, not a replacement; Zeta keeps the + in-process F# surface AND exposes one-or-more wire- + protocol endpoints simultaneously. Significant scope — + may slip from v1 to early post-v1 depending on design round outcome. - **F# DSL reimagining SQL for the modern era (v1).** The existing computational-expression sketch (`DSL.fs`,