On 15.04.2017 22:46, hiro wrote:
> 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.
Well, it probably needs an asynchronous interface, where both browser
and mux can send messages to the other side independently. for example,
a bookmark or history browser (which should be separate tools) could
trigger loading new url in an existing browser. At some point, we'll
end up w/ some protocol thats more complex than just pure request-
response text lines. If multi-threading comes in, we need additional
synchronization. So, the grade of complexity will easily reach the
one of a simple 9P implementation (which indeed is pretty simple).
Having 9P as the base would distributed environments, container
setups, etc, a lot easier to maintain.
> 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.
So, the binding between the actual click behavour and its meaning
(middleclick = new, leftclick = change) is within the browser, not
the mux ? hmm, then we also need the configuration within the browser
and at some point some interface to pass config from mux to browser.
I, personally, would prefer the browser processes as minimal as
possible, leaving any possibly customizable behavour to the outside
world.
> 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.
I'd like to keep that out of the browser. It just should tell the mux
to add new entries and query the mux for visited URLs.
> 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.
What's so special about yt ?
> 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.
Yes, that'd be my proposal, too. I'm a bit undecided whether SSL
handling belongs into webfs, but definitively not into the browser.
In general (not just for the web) there's a lot of complexity behind
SSL handling - cert checks, etc. Do we trust in cert hierarchies or
do we wanna peer2peer signing ? How do we manage certs at all ?
There're lots of different approaches and opinions on that, and I
don't like to force anybody into some specific one. Duplicating all
the required configurations in individual applications like browsers
doesn't seem a good idea to me. Instead there should be some dedicated
server interface for that, so anybody could pick the appropriate
implementation he wants.
> 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.
hmm, looks like a quest for filtering proxies.
--mtx
Received on Sun Apr 16 2017 - 23:24:10 CEST