You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
renraku is still about magically exposing ordinary async functions as an api
transport agnostic, http, websockets, postmessage popups/iframes/webworkers, etc
what's different
abandoning json-rpc in favor of a hyper-efficient custom binary protocol
Conduit is a simple primitive for binary messaging
renraku's Rpc layer works on top of a conduit to provide RPC functionality
🧐 automatic transferables -- when on a medium that supports transferables, all transferables will be transferred automatically -- buffers, offscreencanvas, frames, etc -- no more weird [tune] syntax
🤯 automatic stream support -- you can just pass streams over the wire like normal, and it'll magically work
why
i really really really want streams to magically work
i'm sick of the funky tune syntax
i don't actually care that much about json-rpc 2.0 compat, especially since it doesn't support streams
i super want better efficiency than json-rpc, and a sub-layer of primitives that allow me to ergonomically make a messaging system where each message type is identified by a single damn byte, i mean like EFFICIENT
i want streams
what will be hard
first, this will involve inventing a binary format for json data, extended to support streams, bigints, fancy stuff like that, might as well throw in maps and sets or whatever too
a new vision for renraku v0.6
what stays the same
what's different
Conduitis a simple primitive for binary messagingRpclayer works on top of a conduit to provide RPC functionality[tune]syntaxwhy
tunesyntaxwhat will be hard