alt-f4.der.moe

MoeNavigator progress

After months, I have continued to work on the refactorisation of the network stack of MoeNavigatorEngine, the web browser engine of MoeNavigator.

In the new network stack, the Request class (and especially the derived HTTPRequest class) get a central role in handling request and response data. They interact directly with the network handler on the one side and the engine core on the other side. The architecture should be able to allow synchronous and asynchronous network requests in the future. At the moment, the code to read data from an URL in MoeNavigatorEngine reads response data in chunks using a synchronous approach.

During implementation of the new network stack, I thought about including libcurl, but it couldn't be integrated into the new network architecture, since it doesn't allow separating transfer protocols like HTTP from the underlying network functionality. For a web browser engine, I think it is necessary to have the full control over each bit of HTTP data that is sent or received. So the network stack of MoeNavigatorEngine continues to use POSIX sockets directly without a library in between and protocols are implemented in classes derived from the Request class.

There are still some tasks to be done before the network refactorisation is finished. The progress can be seen here: https://codeberg.org/moenavigator/moenavigatorengine/issues/9

The "network-refactorisation1" branch in the git repository contains the current state of the refactorised network code. It is still unstable, method signatures and interface definitions may still change.


Info
MoeNavigatorEngine is my attempt to write a web browser engine.

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

# # # # #
Thinking about the new network architecture, it seems that middleware modules between a request and the network handler can easily be added, especially if the middleware implements the NetworkHandler interface. Support for TLS could be added by telling Request objects to interact with a TLS-NetworkHandler which in turn interacts with the "real" network handler. Of course, malicious plugins could hook themselves between the TLS-NetworkHandler and the Request object and read all data, but then again, you should know what you are doing when installing plugins.
Built-In TOR support would be possible by adding a middleware module between the TLS middleware and the "real" network handler.