Stato dello stack Web

seed attualmente non fornisce un framework web operativo in linguaggio pulito. Il livello più alto Grove albero contiene un sostanziale stack web storico, ma i suoi pacchetti principali non sono stati portati nella sintassi, nel modello di proprietà, nelle interfacce e nei contratti di runtime dell'operativo LLVM compilatore.

Superficie operativa attuale

Il compilatore pulito attualmente mette in scena solo le basi rilevanti per il futuro lavoro web:

Package/capability	Superficie attuale
`net`	apertura stream-socket IPv4 di proprietà e accesso al descrittore
`web_core`	blocco limitato HTTP letture dell'intestazione, analisi dell'intestazione della richiesta con copia zero e scritture complete con `EINTR` riprovare
`io`	digitato partial/read-all input e scrivi tutto text/byte uscita
`byte_buffer`	costruzione fallibile del buffer di byte inizializzato
`text`	cursore token delimitato da ASCII senza allocazione
`parse`	ha controllato l'analisi degli interi
`task`	canali strutturati, join, eventi, cancellazione e sincronizzazione
`bytes` / `shared_bytes`	proprietà binaria unica, mutabile e condivisa di sola lettura
`str` / fette	controllato la provenienza preservando le viste prese in prestito

Questo è sufficiente per costruire e testare componenti di rete di livello inferiore, ma non è ancora un HTTP server, router, sistema middleware, TLS stack, motore di modelli, livello di sessione o runtime Web di produzione.

Grove corpus web

Directory come queste si trovano sotto grove/libs/:

web
web_core
web_request
web_response
web_runtime
web_middleware
web_security
web_static
web_template
web_db
web_metrics
websocket_server

Conservano API significativo e il lavoro di implementazione di una generazione di linguaggio precedente. Stanno portando input, non pacchetti puliti attuali. Ad esempio:

./seed/seed check grove/libs/web/src/lib.sd

attualmente non riesce durante l'analisi perché la fonte utilizza nomi nominali legacy in maiuscolo e forme aggiuntive sostituite. Di conseguenza, esempi che restituiscono tipi come WebAppStable, WebContext, o WebResponse non devono essere presentati come puliti dal punto di vista operativo seed codice.

Requisiti per uno stack web operativo

Un pacchetto Web Grove diventa attuale solo dopo aver soddisfatto tutti i seguenti requisiti:

Utilizza una sintassi pulita del serpente inferiore e supera l'operativo parser/type controllore.
Sostituisce le chiamate runtime legacy implicite con i pacchetti ordinari attuali o interfacce runtime controllate esplicite.
Utilizza bytes/shared_bytes di proprietà e porzioni prese in prestito per richieste binarie e organismi di risposta.
Rende visibili gli effetti di allocazione, blocco, panico, I/O, FFI e non sicuri.
Codifica la proprietà di socket, connessione, corpo della richiesta e buffer di risposta con pulizia esatta.
Conserva la provenienza input/receiver per intestazione, percorso, query e zero copie visioni del corpo.
Fornisce errori digitati per analisi, trasporto, TLS, timeout e applicazione fallimenti.
Produce e consuma le attuali interfacce .sdi senza fallback dell'origine.
Dichiara i requisiti platform/runtime e fornisce INSTALL.md per FFI.
Passa positivo, negativo, disinfettante, input in formato non valido, cancellazione e separate-compilation tests.

Affermazioni di produzione

Fino a quando tali requisiti non saranno soddisfatti, la documentazione seed non dovrà richiedere il supporto attuale per:

produzione HTTP che serve o instrada;
TLS client/server verifica;
middleware del framework, sessioni, CSRF, CORS, modelli o file statici;
WebSocket;
Prestazioni del prodotto compatibili con TechEmpower attraverso lo stack pulito;
uso diretto delle importazioni web Grove da parte delle applicazioni attuali.

I benchmark storici sul codice Grove potrebbero rimanere come prove storiche esplicitamente etichettate. Non stabiliscono un supporto operativo per la lingua attuale.

Direzione del porting

La più piccola fetta verticale credibile è:

owned socket → bounded read into initialized byte buffer
             → checked request-line/header parser over borrowed views
             → owned response bytes → write_all → exact connection cleanup

Routing, middleware, TLS, pooling, modelli e livelli applicativi superiori dovrebbero basarsi su quella sezione di trasporto verificata anziché preservare le API legacy esclusivamente per la compatibilità della sorgente.

Tieni traccia delle priorità dell'ecosistema in Library Roadmap. La corrente compiler/library il confine è documentato in Riferimento della libreria operativa, e Grove le regole di compatibilità sono in Grove Albero di compatibilità.