[haiku-development] Plan for NetServices Kit (v2)

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 30 Aug 2021 06:13:54 +0100

Hi all,

This is going to be a long one and there is no easy TL;DR, so grab some
coffee.

I have been looking at the state of the netservices and see how it can be
improved. From my review, I identified three main problems in the current
API:
1. While the API is designed to be asynchronous, every request spins up in
a separate thread, which is an efficient way of using system resources.
2. The API design tries to be unified and therefore is quite prescriptive
on what a request is and how it works. This does not work well for all
protocols, especially those that rely on keeping server connections open
(FTP, HTTP2 and 3).
3. The API implemented a callback interface, which executed callbacks
within the context of the dedicated request thread. This is problematic, as
it does not impose any locking on the code that is executed, and thus
invites data races

In my opinion, if we want to continue to provide a Haiku-centric way of
performing network requests with multiple protocols, then we should (1)
provide specific implementations for each of the protocols (BHttpSession,
BGopherSession, BFtpSession) and (2) an easy API to just 'get data at a
URL' for protocols that support an easy download (BUrlDownload).

I have done some preliminary designing and put it up in a repository,
including some exploratory code (emphasis on the exploratory part, meaning
it is not fully functional, inconsistent, does not meet all the style
guidelines). See it here: https://github.com/nielx/haiku-netservices-rfc

I am now thinking on how to best go forward. I think it breaks down into
the three discussions/topics below.

1. The first is the overall redesign at a high level, how does everyone
feel about the approach of breaking it down for multiple protocols with a
common downloader interface?

2. Then there is another discussion of how to implement this in the light
of modern C++. The GCC 8.3 compiler has pretty complete C++17 support, and
while I imagine there are different feelings about modern C++ and the
direction it is going, there is no denying it is here and that it makes
sense to start thinking and discussing what it means for Haiku. Initially
my thought would be to make the new API available both for the x86_gcc2
platform and the x86 platform, but I am starting to change my mind... I
actually think I would like to keep the support on x86_gcc2 to a minimum
(up to the level that is needed for the package kit), and really go to
places on the modern compiler. This will make it so that we can take
advantage of move semantics, smart pointers, constexpr, some
metaprogramming and new features in the standard library.

3. And the final part is about how to approach this. This will obviously be
a lot of work, and I do not want to overload regular code review. There is
also a question about how we vet and validate the internal design. The
options are:
(a) keep working in a separate repository, implement the gaps, do testing
and error checking, and when there is a minimum definition of done, then
merge and refine it on the main repository
(b) go for a feature branch in the Haiku repository so that we can use
regular methods of peer review to make it progress properly
(c) work in a `netservices2` directory structure in the master branch and
continue from there.

I am hoping for some insights and discussion.

Regards,

Niels

Other related posts: