1 |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ |
2 |
On Saturday, September 5, 2020 1:09 PM, Wols Lists <antlists@××××××××××××.uk> wrote: |
3 |
|
4 |
> Isn't that how the web originally WAS designed? That the web-site sent |
5 |
> content and the browser determined how it was displayed? |
6 |
|
7 |
sort of. it was not very clear and they could've |
8 |
gone either direction. so they had to answer the |
9 |
question: where to go? they thought a bit and |
10 |
concluded: |
11 |
|
12 |
"let's go turing-complete with built-in drm |
13 |
and enough fluff to make viewing a 2D page |
14 |
(e.g. cnn.com) take almost twice as much RAM |
15 |
as that of a 3D game (e.g. quake-iii) [1]. |
16 |
but remove marquee!" |
17 |
|
18 |
even though i dislike how the web ended up being, |
19 |
there is one side effect that i like: |
20 |
|
21 |
- making the web turing-complete served as an |
22 |
experiment to explore what humans want. if |
23 |
web devs didn't have the power to freely do |
24 |
things, we wouldn't have known what do they |
25 |
want, and which idea is good/bad. |
26 |
|
27 |
of course, the web also morphed into other messy |
28 |
things that didn't have any good side effects. |
29 |
such as the drm, and the many information leakages |
30 |
that are so ridiculous they effectively render |
31 |
"authentication" sort of redundant; google may |
32 |
identify us by our browsers' fingerprints and call |
33 |
it a day. as if not enough, goog also graciously |
34 |
give us x-client-data for free [2]. |
35 |
|
36 |
that said, i think the decades old experiment is |
37 |
over, and i think we've seen enough to conclude a |
38 |
few things from this experiment. i suggest that |
39 |
we must deprecate http/js/css/etc, and split the |
40 |
web into two components: |
41 |
|
42 |
(1) page content definition format (PCDF): an |
43 |
efficient binary format that only defines |
44 |
content, with no presentation information. |
45 |
|
46 |
imo this is very doable because, while the |
47 |
content in the web varies drastically, their |
48 |
_type_ is pretty finite (e.g. nav bar, |
49 |
copyright notice, related topics, body, etc). |
50 |
i think if we survey websites, it is easy to |
51 |
see that there is only a small number of |
52 |
content types. |
53 |
|
54 |
the client obtains PCDF documents via https |
55 |
then presents them based on user's viewing |
56 |
preference which is purely defined locally in |
57 |
his computer (the server has no business in |
58 |
knowing any of it). this way navigation |
59 |
bars, copy right notices, etc are placed in a |
60 |
standardized manner for every user based on |
61 |
what he cares most about. |
62 |
|
63 |
this way, we won't need to mess up with user |
64 |
style sheet hacks per website. plus page |
65 |
size will become extremely small, and |
66 |
ridiculously efficient to render thanks to |
67 |
the binary format, and much ore responsive. |
68 |
it would be so fast you'd feel that the page |
69 |
has loaded even before you clicked on the |
70 |
link. |
71 |
|
72 |
(2) application containers: this is the part why |
73 |
the web has javascript support, and this is |
74 |
still a part where is not clear to me if we |
75 |
actually need it. |
76 |
|
77 |
i think this is also very redundant with many |
78 |
alternatives doing basically the same thing, |
79 |
such as docker. |
80 |
|
81 |
maybe this is just "package manager in a |
82 |
glorified chroot"? |
83 |
|
84 |
this side is still unclear to me, and i don't |
85 |
know where it is going. |
86 |
|
87 |
--- |
88 |
[1] https://www.networkworld.com/article/3175605 |
89 |
[2] https://www.theregister.com/2020/03/11/google_personally_identifiable_info/ |