i2p/haiku-beta6
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

NetServices: Add libnetservices2.a from dev/netservices into master

Browse Source 
The overall design does not deviate much from my proof of concept [2] and that still makes a good read to
understanding the overall architecture. If you want to get a sense of how it is built up, the API comes with
full doxygen documentation for the public API [3], and I have also done a PoC change for HaikuDepot which is
useful as an illustration on what the impact for the user of the new library is. [4] There is also a test suite
that may give some insight into the day to day ergonomics of the API [5].

The current state is that I am fairly confident that many HTTP requests will actually work, but I do expect
rough edges with a protocol with this many diverse implementations. There is also a list of features yet to be
implemented on Trac [6]. Additionally, I still want/need to do performance testing.

The goal of merging the kit right now is to start making it available for more uses, and through that also give
a chance to shape its future. There are also some design decisions that need review, most notably I expect some
discussion around the uses of C++ 17 idioms (like std::optional and std::string_view) and around the use of
exceptions for error handling.

The impact of merging right now should be near zero: the netservices2 kit lives in its own header space, and
builds into its own static library (libnetservices2.a). It is not yet used in any of the apps in our
repository.

The branch does remove the deprecated services kit from the libnetapi.so library, though it leaves
libnetservices.a intact. After our previous announcement to remove it after beta 3, this should be expected.

[2] https://github.com/nielx/haiku-netservices-rfc/tree/exceptions
[3] https://git.haiku-os.org/haiku/tree/docs/user/netservices?h=dev/netservices
[4] https://review.haiku-os.org/c/haiku/+/5692
[5] https://git.haiku-os.org/haiku/tree/src/tests/kits/net/netservices2?h=dev/netservices
[6] https://dev.haiku-os.org/wiki/Development/NetServices2

Change-Id: I5d0b7e2619699f39a2506588417b57391f0f5cc2
This commit is contained in:
Niels Sascha Reedijk
2022-11-02 01:37:17 +00:00
parent 2710b4f5d4 8672fc2739
commit 1111dda699
18 changed files with 115 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/develop/release/milestones.rst
+1 -1
View File
@@ -36,7 +36,7 @@ Branch
**Time:** ~ 1 week
* Update the version constants in master (example: hrev52295)
* Update the version constants in master (`example: hrev52295 <https://git.haiku-os.org/haiku/commit/?h=hrev52295>`_)
* Branch haiku and buildtools (git push origin master:r1beta1)
* Update the version constants in the branch (`example <https://git.haiku-os.org/haiku/commit/?h=r1beta1&id=b5c9e6620ee731bd33d8cb3ef6ac01749122b6b3>`_)
* Update copyright years in the `bootloader menu <https://git.haiku-os.org/haiku/tree/src/system/boot/platform/generic/text_menu.cpp#n212>`_
docs/user/apidoc.dox
+20 -19
View File
@@ -200,10 +200,10 @@
There are two different cases where you must or could use these blocks:
1. For non-public API of a <em>public header file</em>, you must always
add the classes and other elements to the documentation (even if they)
-# For non-public API of a <em>public header file</em>, you must always
add the classes and other elements to the documentation even if they
are placeholders, and put them in the conditional block.
2. For parts of the non-public API that is in a <em>private header
-# For parts of the non-public API that is in a <em>private header
file</em>, you could put the documentation in a conditional block. If
you choose to do so, you must document all elements in that header
file.
@@ -226,13 +226,13 @@
- \<single_word\> - The argument is a single word.
- (until the end of the line) - The argument runs until the end of the line.
- {paragraph} - The argument runs for an entire paragraph. A paragraph is
ended by an empty line, or if another command that defines a \ref
commands_sections sections is found. Note that if you use commands that
work on a paragraph and you split it over multiple lines (because of the
maximum line width of 80 characters or because it looks better), you
will have to indent subsequent lines that belong to the paragraph with
two more spaces, making the total of four. This is to visually
distinguish paragraphs for other documenters.
ended by an empty line, or if another command that defines a \link
commands_sections section \endlink is found. Note that if you use
commands that work on a paragraph and you split it over multiple lines
(because of the maximum line width of 80 characters or because it looks
better), you will have to indent subsequent lines that belong to the
paragraph with two more spaces, making the total of four. This is to
visually distinguish paragraphs for other documenters.
\subsection commands_definitions Block Definitions
@@ -273,8 +273,8 @@
If you have a look at the output that Doxygen generates, you can see that
there are recurring sections in the documentation. Documentation that
belongs to a certain section should be placed after a command that marks the
start of that section. All the commands take a paragraph as answer. A
paragraph ends with a whitespace, or with a command that marks a new
start of that section. All the commands take a paragraph as argument. A
paragraph ends with an empty line, or with a command that marks a new
section. Note that this list only shows the syntax of the commands. For the
semantics, have a look at the next section on style. In member documentation
you can use the following:
@@ -423,7 +423,7 @@
you will end up using every now and then. This section will describe those
commands.
The first one is \c \\n. This commands sort of belongs to the category of
The first one is \c \\n. This command sort of belongs to the category of
markup commands. It basically forces a newline. Because Doxygen parses
paragraphs as a single contiguous entity, it's not possible to mark up the
text using carriage returns in the documentation. \c \\n forces a newline in
@@ -453,8 +453,8 @@
Finally, it is a good idea to link between parts of the documentation. There
are two commands for that. The first one is \c \\ref, which enable you to
refer to pages, sections, etc. that you created yourself. The second one is
\c \\link which refers to members. The first one is takes one word as an
argument, the name of the section, and it inserts a link with the name of
\c \\link which refers to members. The first one takes one word as an
argument, the name of the section, and it inserts a link with the text of
the title. \c \\link is more complex. It should always be accompanied by \c
\\endlink. The first word between the two commands is the object that is
referred to, and the rest is the link text.
@@ -595,7 +595,7 @@
-# End with a list of references to other classes, functions, pages, etc.
that might be of interest to the reader.
When documenting classes, don't be to exhaustive. Avoid becoming a tutorial
When documenting classes, don't be too exhaustive. Avoid becoming a tutorial
or a complete guide. This documentation is for reference only. If you want
to enlighten the reader on bigger subjects, consider writing a separate
documentation page that connects the different points you want to make.
@@ -623,7 +623,8 @@
clear description. The description starts with a capital letter and ends
with a dot. Don't write the description saying what the method does,
like "Starts the timer", but rather as what it will do: "Start the
timer." -# If the brief description doesn't cover all of what the method
timer."
-# If the brief description doesn't cover all of what the method
or function does, then you can add a few paragraphs that explain it in
more depth. Don't be too verbose, and use an example to illustrate
points. Point out any potential misunderstandings or problems you expect
@@ -646,7 +647,7 @@
In case of overloaded members, you'll need to make a decision. If you need
to copy too much information, you might resort to putting it in one
paragraph with the text "This is an overloaded member function, and differs
from \<name\> only by the type of parameter it takes." That will keep the
from <name> only by the type of parameter it takes." That will keep the
copying down and will point developers right to the place where they can get
more documentation.
@@ -693,7 +694,7 @@
depend on this variable.
Defines are usually used as message constants. Give a short description of
what the message constant stands for, and where it might be send from and
what the message constant stands for, and where it might be sent from and
where it might be received.
Enumerations can either be anonymous or named. In case of the latter, you
docs/user/book.dox
+6 -6
View File
@@ -502,13 +502,13 @@ snooze_until(time - Latency(), B_SYSTEM_TIMEBASE);
prevent this, Haiku implements a \"locking\" mechanism, allowing one
thread to \"lock out\" other threads from executing code that might
modify the same data.
- \b Archiving \b and \b IO. These classes allow a programmer to
- \b Archiving \b and \b IO. These classes allow a programmer to
convert objects into a form that can more easily be transferred to
other applications or stored to disk, as well as performing basic
input and output operations.
- \b Memory \b Allocation. This class allows a programmer to hand off
- \b Memory \b Allocation. This class allows a programmer to hand off
some of the duties of memory accounting and management.
- \b Common \b Datatypes. To avoid unnecessary duplication of code
- \b Common \b Datatypes. To avoid unnecessary duplication of code
and to make life easier for programmers, Haiku includes classes that
handle management of ordered lists and strings.
@@ -551,9 +551,9 @@ snooze_until(time - Latency(), B_SYSTEM_TIMEBASE);
- BString allows strings and provides common access, modification,
and comparison functions.
- BStopWatch allows an application to measure the time an action takes.
- \ref support_globals "Global functions"
- \ref TypeConstants.h "Common types and constants"
- Error codes for all kits
- \ref support_globals "Global functions"
- \ref TypeConstants.h "Common types and constants"
- Error codes for all kits
\defgroup translation Translation Kit
docs/user/interface/_interface_intro.dox
+1 -1
View File
@@ -43,7 +43,7 @@
The initial coordinate space, from which all others are derived, is the
screen space. Its origin is at the center of the screen's top-left pixel.
Coordinates can be converted between this and a specific window or view
space is done using the ConvertToScreen and ConvertFromScreen methods of
space using the ConvertToScreen and ConvertFromScreen methods of
the corresponding object.
Each BWindow has its own coordinate space. Its origin is at the center of