There's currently no way for an application to convert between view and
drawing coordinates with a drawing states stack without keeping track of
all the transformations itself, which is not very convenient for helper
or library functions.
Handle other spaces too, for good measure.
Change-Id: Ic8404a1c111e273fff1eebf2f9f59f58246b796c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5775
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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 smart pointer is designed to help with putting some explicitness and
safety around the case where someone will use their own object that implements
the BDataIO interface to store the body of a network request. By default,
BDataIO objects do not require or enforce thread safety. Since accessing these
unsynchronized objects between two threads is undefined behavior, it should be
explicitly discouraged.
The BExclusiveBorrow/BBorrow smart pointer helper helps solve that by enforcing
the limitations on using an unsynchronized object in two threads. When used
correctly, there is a runtime check on incorrect use by the developer. This
should help write better code.
The design is based on shared_ptr, including having an admin block akin the
control block, that manages the internal object. This type-erased admin block
has the advantage that it allows the owner to have a different type than the
borrower. It also handles cases where the lifetime of the borrower is longer
than the owner: the borrower can continue to use the object until they want to
return it, after which it will be cleaned up. This will make it possible to do
some fire and forget pattern in the network services kit, where someone may
just wants to create a file and borrow it to the network request, and care
about further processing the file in the future.
Change-Id: Ie9b7e7472c868b60f663b4db4fa449d421e447eb
These allow for additional messages about the progress/status of the request.
For now, the messages are sent unconditionally, though it may be reasonable to
in the future switch to sending them only when enabled.
Change-Id: Ic45a0055037af02c689494fa5ce0acd03592ad7e
This fixes a bug in the HttpAuthTest, and in general, moves responsibility of determining
the shape and size of the content to the right place.
Still to do is to fix the case where there really is a variable length content. This will
now probably error out as a connection closed error.
Change-Id: I13c20028e834cc9af8c7bc1d7d7613bf60838e64
This change allows the user to control how many concurrent request can be done
per session. This is going to be helpful to running the tests as well; they were
all fired up in parallel, which sometimes leads to our test server refusing a
connection.
Change-Id: I4f1f40b28b8e0199ea5589b36cd8d00ecd849a63
The integration PostTest has a basic test that the expected messages are sent and
have the expected data fields. The gist is documented in book.dox.
To do are the messages around SSL. However, that functionality is also not
implemented yet, so there is nothing to send.
Change-Id: Ib8f36ed32f9854d643d8256338b71af7067059f0
In the old service kit, the Accept header was automatically set. However, it is
not a required header. This removes the default value and the protection against
setting it manually.
Required to make HaikuDepot work.
Change-Id: Ic589bfc5829db25915b67f2a13b6c2436c053e25
This commit introduces a simple thread-safe ring buffer implementation
based on top of BDataIO. The main use case for this class will be to
implement shared buffers between threads for the upcoming refactoring
of Services Kit.
Change-Id: I526bc044b28c91496ad996fabebe538e75647f2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2966
Reviewed-by: Jacob Secunda <secundaja@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The description of the callback function was still quite confusing. The
main usage for the return argument from the callback function is not
handling failures, but knowing wether the function did something in the
list or not, and stopping the iteration if only one item was looked for.
Add an example use of the function return value to implement a linear
search in the list and remove the note about the function "failing",
which is not what this parameter was meant to do (and I think that lead
to the initial inversion of "true" and "false" values.
Change-Id: If8cae8b8ee21ced2c899aef6033a89ab8dbf1621
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5339
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* The function passed to `DoForEach` returns `true` to terminate
the loop early
Change-Id: If445836b14c44b981d169564e7beab8c0ecac36f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5336
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These utilities convert timestamp strings that are formatted according to
the HTTP RFC into BDateTime objects, and vice versa.
Change-Id: Ia2498944fb63d09233839f19d08f15d82a0a9685
The user of the API can set whether redirects should be followed, and if so,
how many. This is part of the BHttpRequest API. The BHttpSession then follows
those instructions, and executes the maximum number of redirects the user
would like to follow.
As part of this commit, the BHttpStatusClass and BHttpStatusCodes helper enums
have been added, to give a friendlier access to HTTP status codes and status
classes.
Change-Id: Ic8c9e3fda158e2cce549c8f1d360951f7ac83311
These particular responses will not have a body. This is now handled by the
BHttpSession object. There is also a minor fix in here that prevents a crash
when multiple requests are handled by the DataThread at the same time, and not
all of the requests have events.
Change-Id: I7f47d8b3cd8491c8193275be4b3fc1080780fa20
This change also drops the principle that fields with the same keys would be
grouped together. This was initially inspired by Boost::Beast, but it means a
lot of extra copying of data when adding/organizing the list, as well as
inefficient querying on each add. Now that the design choice is to fully go
for the raw string as underlying data storage, that choice is not necessary.
In the future it may be able to emulate the grouping or retrieving of lists
of values in the API, rather than as a fundamental principle of the data
storage.
Change-Id: I2667cfa38eb3b7b75393ee71fb038231a40b4193
BHttpSession::Execute() moves the request into the session, and returns a future BHttpResponse
object. Currently implemented are resolving the hostname, and opening the connection.
There is some scaffolding for the actual data transfer.
Change-Id: I5a8a7a7f8680036b91cdba4beee140bbed6bfd5a
This is a generic error type that can be used by multiple protocols to describe errors that can
occur while processing a request. The error type supports adding an additional error code in cases
where there is an underlying system error.
The type will be used to describe errors that occur while processing requests by BHttpSession, and
it is generally going to be thrown by the receiving BHttpResult.
Change-Id: I76c0bbaedd38df8cfb79159c4beae2fbf1350aab
Incomplete class, but will provide the basis to start working on the internals of the BHttpSession.
Change-Id: I3ca14b7bd823fc1b4a5a32f5784592d214c4e9a7
Objects of this class describe a HTTP request. It contains several convenience
functions that will allow a user to describe the properties of the request.
More options to be added later.
Change-Id: If6a00d26808c5ed4b121cb36dc75a2a1cc449f95
This class provides defaults and performs basic validation for HTTP Methods as
defined by the standard. They will be used in conjunction with a future
BHttpRequest class.
Change-Id: If69a7ec186d9d1165e8efe5ab5df50d5a089208d
HTTP messages (requests and responses) have a header section that can contain
HTTP headers. These headers consist of name, value pairs. This class can be
used to query the headers on a response, and build a list of headers for a
request.
The internal implementation is designed around two different methods of storing
the underlying data. For HTTP requests, the name, value pairs are stored as
owned BString objects. For responses, the assumption is that there is a byte
buffer that contains the data and that has the same lifetime as the BHttpFields
object. The name, value pairs will then be stored as std::string_view to the
underlying buffer.
Still to do is:
- The method to convert a BHttpFields list into a string buffer to transmit.
- The method to parse a string buffer and turn it into a BHttpFields object.
Change-Id: I4819db100aa1671aa7403675216a4c85fd221da7
Found by Scottmc.
Change-Id: Idd10040d798533a0aa731132f7282e7ce1423ed6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4687
Reviewed-by: humdinger <humdingerb@gmail.com>
This implements the "rule of 5" for this type. While the copy operation for
BString was already using shallow copies of the underlying data, this change
further optimizes moving the data from one object to another.
While it is not the intention to implement move semantics to all types in the
legacy Haiku/Be kits, data types like BString are good candidates, because move
operations are often useful when working with data within an application.
In this implementation, the internal data of the string object will be set to
NULL, thus leaving an empty string.
Change-Id: I16bf9424f9b17f622b0b57659b80628e18760288
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4428
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
