diff options
Diffstat (limited to 'integrating_browser_into_your_environment.html')
| -rw-r--r-- | integrating_browser_into_your_environment.html | 81 |
1 files changed, 0 insertions, 81 deletions
diff --git a/integrating_browser_into_your_environment.html b/integrating_browser_into_your_environment.html deleted file mode 100644 index e67bfea..0000000 --- a/integrating_browser_into_your_environment.html +++ /dev/null @@ -1,81 +0,0 @@ -<!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> |