1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="author" content="aki">
<meta name="tags" content="web, browser, unix philosophy">
<link rel="icon" type="image/png" href="cylo.png">
<link rel="stylesheet" href="style.css">
<title>Integrating Browser Into Your Environment</title>
<nav><p><a href="https://ignore.pl">ignore.pl</a></p></nav>
<article>
<h1>Integrating Browser Into Your Environment</h1>
<p class="subtitle">Published on 2020-08-12 23:15:00+02:00
<p>Not so long ago I've finally started to play around with a little idea I had when I was writing
<a href="markdown_is_bad_for_you.html">the rant about markdown</a>. That little idea was to split web browser into
possibly several smaller utilities with a distinct responsibilities. In other words, to apply Unix-ish philosophy in a
web browser. I've touched this idea in <a href="web_browsers_are_no_more.html">Web browsers are no more</a> and then
did some initial tinkering in <a href="plumbing_your_own_browser.html">Plumbing your own browser</a>. Now time has come
to draw conclusions. Think of this post as a direct update to the plumbing one.
<p>I don't like IDEs. I have hand-crafted environments that I "live in" when I'm working on any of my computers. Window
manager that I tinkered to my liking, my preferred utilities, my text editor, my shortcuts. Whole operating system is
configured with one thing kept in mind: it belongs to me. IDEs invade this personal space of mine. And so do web
browsers. Of course, you can configure both web browsers and IDEs to some extent. You can even integrate them closer to
your normal environment, but in my experience sooner or later you'll run into limitations. Or you will end up with IDE
consuming your entire operating system (hello, emacs!). I didn't like that.
<p>Thanks to the amount of alternatives I can happily avoid using IDEs. I can't say that about browsers. Moreover modern
browsers are enormous and hermetic. Usually the only utility you have to interface with them is <code>browse</code>
which in turn is usually just a symbolic link to <code>xdg-open</code>. Not only that, but they only to open links in
their rendering engine and may allow to save a file, so that user can use it once he leaves the browser alone.
<p>Because of that, and because of other reasons I described in before-mentioned articles, I decided to try if splitting
browser into smaller utilities is a viable option, and just play around this idea.
<p>For now, I've split it into four parts, but I can see more utilities emerging:
<dl>
<dt>request solver
<dd>Previously, I referred to it as "browse" utility. But the way I have "browse" implemented now implies more than just
one responsibility. On the other, the request solver is meant to only oversee a request. It means it has all the pieces
of information and passes them to utilities in order to complete the request. It interacts with most of other programs
and may interact with user.<br>
It's one of the most important parts of this system. Due to nature of more verbose media like websites it should support
more than just "get this URI and show it in a view". For instance, it should be able to allow user (or view) to open the
resource in currently used active window or just retrieve files without opening them (in case of e.g. stylesheets). I
believe that there is enough room in here to separate even more utilities.
<dt>protocol demulitplexer
<dd>This one is also a part of the "browse" as of now, just because at this stage it can be a simple switch case or even
non-existent, assuming I plan to support only one protocol (e.g. http). One could pass this responsibility to the file
system, if protocols were to be implemented at this level (the Hurd-ish way).
<dt>protocol daemon
<dd>Not really a daemon (but it can be one!). Retrieves and points to data needed by the request solver.
<dt>opener/view demultiplexer
<dd>Your usual <code>xdg-open</code> clone. A more verbose switch case that opens the resources in appropriate views.
<dt>view/view engine
<dd>Displays the retrieved resource to a user. It's aware of its content and may request secondary files through request
solver (again, e.g. stylesheet or an image). Displays hyperlinks and redirects them to request solver. It's almost
completely agnostic to how they should be handled. It may suggest request solver to open the link in current view, if
the resource type is supported and the view is desired to handle this type of resource.
</dl>
<p>Now then, implementation currently have request solver and protocol demultiplexer in one utility called "browse". I
see quite a lot of opportunities to split the request solver a little bit more, or at least move some of the tasks to
already existing programs. Nonetheless, they're way more separated than most modern browsers.</p>
<img src="integrating_browser_into_your_environment-1.png" alt="demux, I really like this word">
<p>The biggest pain in all of this is an HTML engine. The more verbose ones were never intended to be used like this.
On the other hand the limited one that I wrote just for this experiment is... Well, way too limited. It allows me to
browse simpler websites like my own, but has problems in those that have CSS that's longer than the website content.
Of course, I don't even mention modern web applications, obviously they won't work without Javascript.
<p>Surprisingly, despite the enormity of problems mostly related to HTML, CSS or Javascript, I'm staying positive. It
works, it can be integrated in the environment and it's an interesting idea to explore. For some reason it feels like
I took <code>xdg-open</code> to extremes (that's why I keep mentioning it), but I think it's just because I am yet to
polish the concept.
<p>For now, <a href="https://git.ignore.pl/browse/">the utilities</a> are available publicly. You can use them to try
out the idea. I've left there one simple example that uses <code>dmenu</code> for opening an URI either from list of
bookmarks or one entered by hand. Moving base address and some mime type to command line options, should give the
utilities enough flexibility to use e.g. opener to open local files as well. Then it can be used with <code>lf</code> or
any file manager of your choice, and you'll have single utility to handle all kinds of openings.
<p>I'll move now to other ideas that I left without any conclusion. However, I'm looking forward to seeing if this one
can bring more in the future and most certainly I'll return to it with full focus.
</article>
<script src="https://stats.ignore.pl/track.js"></script>
|
