@bobdobberson once upon a time people designed things for pieces of paper. one of the most common things to was to lay out a grid and fill it with content. people also did this in html. then the W3C said no, how dare you, the table element is for tabular data! so they replaced it with nothing.
then they came up with some bullshit monstrocity called CSS, which can't just make a god damn table like people want it to, so you have to do a lot of ass backward roundabout fuck just to get the grid people wanted in the first place, and the browsers have to deal with a lot of edge cases in this ass backward roundabout fuck to make sure none of the goddamn niche bullshit renders slightly wrong in some inconceivable degenerate configuration.
meanwhile knuth already basically solved this problem for known paper sizes, adobe mostly solved it for flexible sizes (with text fields that flow to another designated cell), and you have things like miglayout and cassowary to handle some pretty extreme constraints in a sensible way, but we didn't use those things, we let idiots do it.
@bobdobberson i would probably just make it a programmable typesetter, and give up on the failed ideas like html<>css. in practice, the html is married to the css. user styles don't really work, except to change a couple of basic colors and fonts.
so i would do something like SILE does where you lay out text boxes, and they flow in to one another, and just expose things like page sizes to the typesetter so when you resize the page it just retypesets the whole thing.
@bobdobberson there's nothing actually wrong with HTTP. the specs a little long in the tooth maybe. i'd rather it have actual packet framing instead of having to yee haw parse text, but apparently nobody in 40 years has decided yee hawing text is something we should address
@bobdobberson i mostly mean the lack of packet framing. you have to read a potentially unlimited amount of freeform text, and then parse that text to find the actual boundaries of headers.
in practice there are limits put on that buffer, but it should have always been <string length><text>
@icedquinn I'm wondering how that solves the problem; if you replace the text of an HttP packet when has a problem of needing to read unknown amounts of data, doesn't a blob need to be fully read in to know how long it is?
Isn't there still the same problem of the client or server has to wait for the complete blob before it can stop reading?
@bobdobberson there's size markers in cbor blobs. you can look at a single byte to see how many more bytes to read to get the size of an element, and that tells you how many bytes to read the rest of the element in.
@icedquinn is it limited in how large a size marker can be?
I mean it seems like you could place a reasonable limit, but I imagine that will cause problems at a future time, if for some reason we need size markers that are 10 million bits in size.
@bobdobberson
> For integers, the count field is the value; there is no payload. Type 0 encodes positive or unsigned integers, with values up to 2^64−1.
if that's somehow not enough, you'll have to use chunked encoding i guess.
@icedquinn I mean, not to be difficult about this, but that is only 2.3 exabytes.
The amount of data we generate and work with everyday, in part because of optimization for developer time, means we might be dealing with sending that kind of data in the next decade or so. (Mostly kidding, but...)
Add comment