From ad76e9b885c9b9692074cf5b8b880cb79f8a48e0 Mon Sep 17 00:00:00 2001 From: Aki Date: Sun, 25 Jul 2021 19:17:40 +0200 Subject: Initialized website as git repository --- integrating_browser_into_your_environment.html | 81 ++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 integrating_browser_into_your_environment.html (limited to 'integrating_browser_into_your_environment.html') diff --git a/integrating_browser_into_your_environment.html b/integrating_browser_into_your_environment.html new file mode 100644 index 0000000..e67bfea --- /dev/null +++ b/integrating_browser_into_your_environment.html @@ -0,0 +1,81 @@ + + + + + + + + + +Integrating Browser Into Your Environment + + + +
+

Integrating Browser Into Your Environment

+

Published on 2020-08-12 23:15:00+02:00 +

Not so long ago I've finally started to play around with a little idea I had when I was writing +the rant about markdown. 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 Web browsers are no more and then +did some initial tinkering in Plumbing your own browser. Now time has come +to draw conclusions. Think of this post as a direct update to the plumbing one. +

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. +

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 browse +which in turn is usually just a symbolic link to xdg-open. 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. +

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. +

For now, I've split it into four parts, but I can see more utilities emerging: +

+
request solver +
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.
+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. +
protocol demulitplexer +
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). +
protocol daemon +
Not really a daemon (but it can be one!). Retrieves and points to data needed by the request solver. +
opener/view demultiplexer +
Your usual xdg-open clone. A more verbose switch case that opens the resources in appropriate views. +
view/view engine +
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. +
+

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.

+demux, I really like this word +

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. +

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 xdg-open to extremes (that's why I keep mentioning it), but I think it's just because I am yet to +polish the concept. +

For now, the utilities are available publicly. You can use them to try +out the idea. I've left there one simple example that uses dmenu 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 lf or +any file manager of your choice, and you'll have single utility to handle all kinds of openings. +

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. + +

+ -- cgit v1.1