wincane no-js

Stavo quasi per finire la parte di base del bridging di messaggi oggi in #WinDog, che grazie alla API cross-platform che ho costruito dovrebbe in realtà essere questione di poco conto... perché si tratta di usare funzioni già esistenti per elaborare strutture dati già pronte, ma in modo diverso. Peccato che c'è qualche inconveniente per come i messaggi vengono sdoppiati, oltre al fatto che per le varie piattaforme ho ancora da implementare una marea di metodi (su tutte mancano modifica e cancellazione dei messaggi, pensa te), quindi mi sono scocciata oggi pomeriggio e ho pensato... ma quasi quasi ci vuole un bel proof-of-concept della futura versione #web del #bot, totalmente funzionante senza #JavaScript... 👽️

Beh, dopo essermi fatta distrarre da altri esperimenti in realtà ho già fatto e finito qualcosa di molto grezzo, però neanche io credevo di riuscirci a questa maniera... Il punto è che, prendendo ispirazione da github.com/kkuchta/css-only-chat (anche se io ho implementato tutto in modo molto diverso, senza la brutta #hack CSS), ho creato una live chat in HTML puro, che si aggiorna di continuo e con latenza bassissima, senza costringere a ricaricamenti della pagina, ma sfruttando il meccanismo pazzoide che ho fatto meglio a illustrare in video. Fatto al volo eh, senza manco il tempo di sistemarlo, tant'è che ci sono dei memory leak sicuri, ma questo sarà un problema dell'Octt del futuro (di domani o chissà quando). 💨️

Non so se lo lascerò ancora prima di sistemare estetica e codice, ma nel dubbio, dovrebbe stare su WinDog.octt.eu.org. Il meccanismo per cui la pagina si aggiorna senza script e senza flickering, lo spiego meglio, è fighissimo: con l'header HTTP Content-Encoding: chunked, il browser è forzato a renderizzare l'HTML senza aspettare che la connessione si chiuda; dall'altro lato, il server non termina mai la connessione (infatti c'è un loop infinito che preleva dati da una coda, e wow, quella struttura ritorna dopo appena un giorno...), inviando via via frammenti di #HTML che vengono appesi in fondo alla pagina. Stranamente, questo comportamento si vede funzionare correttamente solo collegandosi con normali browser o client TCP grezzi (netcat)... curl semplicemente si blocca, invece. E, ancora, il Content-Type deve essere esattamente text/html; charset=UTF-8, basta anche solo omettere il charset per rompere tutto! La casella di invio, invece, è banalmente dentro un iframe. Direi allora che questo è abbastanza #HTTP 1.1 per oggi... 🥰️