the interface is not so hard, browser needs to communicate via lines
of text to one process. for that it has stdin/out. process that starts
the browser can arrange those fds internally as is needed. doing that
for multiple processes is what i called demuxing.
it doesn't need to be a 9p file server, it's too trivial for the
features presented so far.
though it could also be a fifo or file on disk. doesn't matter at all.
when a user middle clicks a link pointing to URL the browser should write:
"new URL"
-> depending on URL open new browser process with that url as argument
-> or open something else, for example mpv
when a user clicks a link normally:
"change URL"
-> same as above
-> if there's no special rule send it back to browser: "change URL".
only then the browser should go there.
current browsers assume the browser *also* has history state. thus the
history selection gui will be provided by browser and we have to
replicate this in some ugly way, unless somebody isn't too lazy to
change that.
when a user presses the #th entry in history list:
"goto history #"
-> if it's a youtube or some shit like that, then handle it in mpv.
otherwise write it back to the browser.
it doesn't need to scale, the amount of information passed around here
is trivially small. you can even write everything directly to disk
like opera does it for me right now.
there's even more to learn from webfs. it does so many things that a
designated file server starts making a lot of sense.
It even includes cookie and SSL handling.
For the future, being at that layer it seems easy to extend, so that
stupid crap could be filtered out of horrible web sites (the kind of
shit mentioned here for example
http://idlewords.com/talks/website_obesity.htm) more easily with
simple shell scripts.
Though webfs currently doesn't save the history or keeps state of
currently open windows in the way i described earlier.
Received on Sat Apr 15 2017 - 22:46:26 CEST