Conversation

Notices

1. Embed this notice
   Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 04:25:06 JST Pope Bob

   Dumb question: Why are current web browsers larger than 10mb?

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 04:25:04 JST iced depresso

     in reply to
     @bobdobberson unrestricted complexity, inelegant coding, and a lot of involvement by google who has never cared for elegance
   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 04:28:09 JST iced depresso

     in reply to

     • iced depresso
     @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.
   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 04:38:00 JST iced depresso

     in reply to
     @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.
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 04:38:02 JST Pope Bob

     in reply to

     • iced depresso

     @icedquinn I had no idea about any of that. I wonder what it would take to create something new that doesn't reinvent wheels.

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 04:43:27 JST iced depresso

     in reply to
     @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
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 04:43:30 JST Pope Bob

     in reply to

     • iced depresso

     @icedquinn or, do we just want to us HTTP to convey the data?

   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 04:43:31 JST Pope Bob

     in reply to

     • iced depresso

     @icedquinn sounds good. What does the pre-rendered file look like, and what port do we wanna put it on?

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 05:03:30 JST iced depresso

     in reply to
     @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>
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 05:03:31 JST Pope Bob

     in reply to

     • iced depresso

     @icedquinn well, the 'flexibility' of yeehawing text does allow you to implement a protocol on top of the sending/receiving, perhaps?

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 05:17:23 JST iced depresso

     in reply to
     @bobdobberson probably just use cbor these days
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 05:17:24 JST Pope Bob

     in reply to

     • iced depresso

     @icedquinn how would you improve it? Have the client and server send a bit count first, then the block of data?

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 05:26:19 JST iced depresso

     in reply to
     @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.
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 05:26:20 JST Pope Bob

     in reply to

     • iced depresso

     @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?

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 05:31:46 JST iced depresso

     in reply to
     @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.
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 05:31:47 JST Pope Bob

     in reply to

     • iced depresso

     @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.

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 05:34:46 JST iced depresso

     in reply to
     @bobdobberson i think most http servers only allow like 16k for headers and thats being generous
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 05:34:48 JST Pope Bob

     in reply to

     • iced depresso

     @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...)

   • Embed this notice
     iced depresso (icedquinn@blob.cat)'s status on Thursday, 11-Apr-2024 05:41:28 JST iced depresso

     in reply to
     @bobdobberson there's still more complexity involved in processing than there has to be.
   • Embed this notice
     Pope Bob (bobdobberson@dobbs.town)'s status on Thursday, 11-Apr-2024 05:41:30 JST Pope Bob

     in reply to

     • iced depresso

     @icedquinn so that sounds like the problem is solved, yeah?

     At most, an HTTP server has to listen for 16kb to know what to do, right?