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
A thought: abi.File should be expanded to contain the idea of a "sub-descriptor", "control descriptor" or another such term. This "sub-descriptor" would fulfill the place of ioctl, accept, stat and other more complicated syscalls. Programs could read/write any structured data in plain human-readable text or msgpack.
constl=tryResource.open("tcp://0.0.0.0:90?mode=host");
for {
constclient=tryl.control("accept");
constclient_meta=tryclient.control("meta");
// read IP address on first line and log?// handle requestclient.close();
}
The text was updated successfully, but these errors were encountered:
"control descriptor" sounds good to me. I'm not sure about the argument in .control("something"). I feel like the platform should multiplex key-value requests written to the control descriptor by itself somehow, and the caller shouldn't really be interested in multiple flavors of control descriptors, unless the surface of the control API is huge, and key collisions are possible.
A thought:
abi.File
should be expanded to contain the idea of a "sub-descriptor", "control descriptor" or another such term. This "sub-descriptor" would fulfill the place ofioctl
,accept
,stat
and other more complicated syscalls. Programs could read/write any structured data in plain human-readable text or msgpack.This would enable things like the following:
The text was updated successfully, but these errors were encountered: