The BufferPool::writeHex() method takes a string-pointer, we add an int
max-number-of-chars to be parsed on that string.
This allows us to not just stop at the first non-hex char, but also
after a set number of characters.
This effectively allows us to use non-zere-terminated strings as
argument too.
This adds endsWith() and an extra startsWith() overload.
We also added tests for the case when either the argument or the object
are empty and specify the behavior. I copied the behavior of QString.
See unit tests that specify the behavior with empties.
As we moved most of the creation of a BufferPool to be via the
Streaming::pool() method, which uses a thread-local, it makes sense
to start cleaning up the design and make it more modern C++.
The above mentioned method would return a reference and you'd see
loads of places use `auto &pool =` which is less than ideal.
As the number of places where we actually instantiate a BufferPool
goes down, the usage of some sort of smart pointer makes more sense.
This now makes all APIs use BufferPool be wrapped in a shared_ptr.
Protocol Buffers interaction is just another serialization standard,
while its widespread it has fortunately mostly been kept out of
anything relevant or important. Mostly due to the fact that is
really quite bad from a technical perspective.
This adds simple and basic support for creating and parsing
protocol buffer messages, mostly to allow interoperability.
If you want quality: use the MessagBuilder/MessageParser ones instead.
Using the forget() method too many times could lead to an invalid
(negative size) ConstBuffer being created.
This fixes and immediately copies an assert used in many other places in
the code already.
THe builder now allows you to create a message with the
serviceId, the messageId and the requestId pre-set.
This benefits code that just takes the output from the
builder and calls 'send' on it immediately saving several
lines of code.
Move some files back to the server "library".
Merge the 'console' lib with server, as it doesn't really make sense with
just one file and nobody exclusively linking to it.
The server "libary" is not really a library, its the place we put all
the files shared by hub-qt hub-cli and hub.
We no longer depend on these files from other places (mostly due to
moving to the new logging framework) and as such we can move the files
back.
tomFlowee
Calin Culianu