Skip to main content

 

MoeNavigator update: The engine got a new network stack


In short: The network stack in MoeNavigatorEngine has been cleaned up and has become more flexible. The tools for the engine have been updated, MoeNavigator got a bit of maintenance.


The refactorisation of the network stack in MoeNavigatorEngine (MNE) has progressed far enough so that the new code has been merged back into the master branch.

The new stack relies on a network handler that interfaces with the network functionality of the operating system and request objects that pass themselves to the network handler when the request starts. The difference to the old stack is that there is no network protocol handler anymore that passes data. Instead, the network handler sends data to the request object's buffer which is then passed to the "other side" of the web browser engine that processes the data in one of its parsers. To avoid polling, mutexes are used as semaphores which get locked when data have been read and unlocked when data is available. The new network stack should also be able to handle asynchronous requests, but that isn't implemented yet.

The protocol support is the same as with the old network stack: HTTP only. But in the new stack, the Request class provides an abstraction layer where protocols are just specialisations of the base Request class. Adding support for other protocols (like gopher) should have become easier with the new network stack.

The HTTP support has improved in the new stack since the header fields are not limited to a certain set of fields. All header fields are treated equal in request and response headers as long as they are valid. The HTTPRequest class doesn't care what's inside the fields, its only repsonsability is to put together the request header, parse the response header and read the response data. I have verified that reading big binary files works using the mneget tool (from the moenavigatorengine-tools repository). To send data via HTTP POST or PUT, the HTTPRequest class needs some more code to send big chunks of request data.

To add TLS support, a layer between the network handler and the request is necessary. How it shall be named is not yet decided, but it will probably implement the NetworkHandler interface so that all methods for unencrypted network access can be available for encrypted network access as well. This would enable support for HTTPS and could add TLS support for all other protocols the engine supports so that theoretically there could be something like "gophers" (gopher secure), once gopher is implemented.

Besides the work on the engine, I updated the tools for it and got mneget, a wget-like program, into a working state. MoeNavigator itself got a little bit of maintenance and an updated about dialog. With the big progress in MoeNavigatorEngine this week, the days of WebKit as default engine in MoeNavigator are numbered.


About

MoeNavigator is a web browser written from scratch in C++. It uses its own engine called MoeNavigatorEngine (MNE). There is also a collection of tools for the engine. The source code is licensed under the terms of the GNU General Public License v3. The repositories are on @Codeberg.org:

- https://codeberg.org/moenavigator/moenavigator
- https://codeberg.org/moenavigator/moenavigatorengine
- https://codeberg.org/moenavigator/moenavigatorengine-tools


# # # # # # # #

 

Software and hardware projects I'm currently working on


MoeNavigatorEngine


My web browser engine written from scratch since 2011. Currently I'm rewriting the network components for better HTTP request handling. The current state of the rewrite is in the "network-refactorisation1" branch of the source code.

Project page: https://codeberg.org/moenavigator/moenavigatorengine

libcuwte


Web template rendering in C++ using common template languages like Jinja2. The project just started but you can already replace variables in Jinja2 templates with it. Check out the test1 program in the source code repository for a demonstration.

Project page: https://codeberg.org/ncc1988/libcuwte

Schlimm


My fork of the SLiM desktop manager. Currently I'm refactorising the code, translating it to modern C++ and making it possible to use schlimm without any configuration file.

Project page: https://codeberg.org/ncc1988/schlimm

open-system-compact-cassette


This is a long-term hardware project where I'm trying to develop circuits and microcontroller code for compact cassette hardware to be able to record and playback digital music from a cassette using modern audio codecs like Speex and Opus. The current task is to find out how to connect GNURadio blocks correctly to input and output data at an acceptable rate using a sound card.

Project page: https://codeberg.org/ncc1988/open-system-compact-cassette

analogtape-utils


This is a collection of tools that help with converting media files for recording compact cassettes and VHS tapes using a computer. The encode_cassette.sh script for compact cassettes handles things like audio normalisation and pitch adjustment for tape recorders that don't record in standard speed. The encode_vhs script compiles all the source video files into one big video file using a Makefile for multitasking. The collection gets new scripts whenever I find a way to automate a part of the media conversion process.

Project page: https://codeberg.org/ncc1988/analogtape-utils

# # # # #

# # # # # #