It's just map<string, string> attrs; that's all.

using aliases are great to convert that piece of non-understandable code into something beautiful.

Lots of changes;
The project is now can't be even built.
Lots of things to do.

I introduced a new idea named "traits" in the project which will help the final user to use a custom Encoding, Allocators, String types, and hopefully in the future encryption algorithms and their corresponding keys.
These things can be changed by passing the custom traits class (which will include some custom types) as template parameter.

I'm afraid some parts may be a little tricky to make them easy to use for the final developers. I hope I can get them right.

The new changes I'm gonna push today.
The project is now can't be compiled again.
Next agenda is to make sure the traits classes are everywhere, and also make the whole project compile-able again.

Do you think this is overkill? You might be right.
The funny thing is that the "__has_include" itself is the newest of them all 😂
Why am I doing that?
I should remove this :)

For quick search in http://cppreference.com website, just add it's search engine in your Firefox browser search engines list and add a shortcut like "cpp" for it.

Then you just have to open up a tab with Ctrl+T and start typing "cpp std::vector" for example.
——————————————————

Or you could use "Zeal" and download the whole cppreference website and use it offline.

cppreference is my goto website for C++ problems.

This is how you can use the NetworkingTS which hopefully will be added in C++23 in C++20.

Here's the source now: https://gitlab.com/webpp/webpp/-/tree/master/core/include/webpp/std

I'm done for today! :)

I don't always write the best algorithms, but that's why the tests and benchmarks are there.
That makes me brave.

Now instead of reading documents, I read implementations.

Now I need to implement a whole bunch of stuff just to create a faster case-insensitive equal operator for string types.

Of course I don't have to; but I want to!

Why std::char_traits doesn't have this implemented?
Well, I'm gonna advance std::char_traits and add some more features, and fall back to bad old fashion std::tolower to implement it.

I wonder what this __builtin_memcmp is!
If it's a good algorithm, sure; but I don't like having to use std::char_type::compare for std::string::operator==, I think there are better ways. We don't need to check the whole strings to know they're not both the same!

My twitter thread about this: https://twitter.com/the_moisrex/status/1254142556029452289

Oh come on,
Now I have to either create two distinct cookie classes, one for request and one for response, or go through the hassle of creating a templated one which will require some template madness in order to make it more optimized for the request header since cookies in request headers don't have as many features as cookies in responses.

Also responses have two different header names for cookies: one Set-Cookie and one Set-Cookie2 which is deprecated for some reason. Thank GOD!

Changing the whole structure of the cookies class.
1hour and 36mins in 28 seconds.

2020-04-26 06-31-30

Changing the basic_uri signature to match the traits templates.
But I have so much of the implementation that I have to change too.

2020-04-26

Converting the rest of the basic_uri, and adding a few useful features like a faster version std::to_string with help of std::to_chars which not clang nor gcc has it fully implemented yet even though it's a C++17 feature.

I think I need to make the whole library a header-only library. By introducing traits, I've been converting every function/class that requires strings of any kind.

A time-lapse that will require a 10 more time-lapses just undo what I was trying to do!

I'm re-designing the whole idea of valves in the project. The final result will have more power than the current idea of valves in the webpp project.

Developing broken ideas!
New ideas are coming for the routing system.

The new routing system:

Problems this system will solve compared to the valving system:
- The migrations now can access the context
Previously it was possible to implement this through some ways but
the problem was that the whole thing was based on requests and
responses, which meant that we couldn't pass other objects and types
without modifying the request and response types which adding a new
parameter into their template parameter lists only introduced more
complexity for the library users
Other ways we could've solved this issue:
- Using virtual inheritance for requests
Would've added unnecessary indirection
- Using self made vtable
Would've added unnecessary indirection
- Using void* type or similar ones and cast them later
Would've added unnecessary indirection
- Passing a context object to the migrations/valves to solve this
Which would've introduced complexity because at that point the
requests and the responses were not retrievable from the context.

- The valves are not aware of the requests and other details provided
by the context.
Previously this was an issue since the valves were only capable of
checking if the request is a match for the valve or not and they
couldn't modify the response or even stop the request or provide
information for the migration.

- A better constexpr way of passing valves and migrations to the router
Since the valves and the migrations were a separate entities which
they would become one entity after creating the "route" template
class, it was a problem to create a nicer looking route by the user.

- Using valves as validators and validators as valves.
Using valves as validators are now easier since the user doesn't have
to create a constexpr variable and use that variable in both the
.on method on router and inside the migration.
Now the whole thing is inside the context, and it'll be passed to the
valves/migrations by reference.
Of course using validators as valves require a bit of a hack from the
user but there's just no other way and honestly it's easy enough to
do so!


Route types:
- Entry routes
- Sub routes

Definitions:
- Route: Possible ways that are capable of handling user requests
- Entry Route: The main routes that will be checked first
- Sub Route: The routes belong to the each Entry Routes
- Context: An object of arbitrary type that will contain everything
that routes will need including:
- Request
- Response
- Previous entry routes context changes
- Previous sub routes context changes
- Original entry routes level context
- Original sub routes context changes


Features we need:
- [ ] Extendable entry and sub routes
- [ ] Use class operator() as a place to add more sub-routes
- [ ] Having access to the context class in the callables
- [ ] Having access to the request and the response
- [ ] Termination of continuation of checking the sub-routes by parents
- [ ] Termination of continuation of checking the entry-routes by any
previous routes, or sub-routes.
- [ ] Context modification
- [ ] Sub-Route local context modification by any previous sub-routes
- [ ] Inter-Entry-Route context modification by any previous
(sub/entry) routes
- [ ] Entry-Route prioritization
- [ ] Auto prioritization
- [ ] Manual prioritization
- [ ] Hinted prioritization
- [ ] On-The-Fly Re-Prioritization
- [ ] Dynamic route generation / Dynamic route switching


Usage examples:
- .on(get and "/about"_path >> about_page)
- ( get and "/home"_path ) or ( post && "/home/{page}"_tpath ) >> ...
- opath() /"home" / integer("page") /
- empty / action_list("action", {"open", "delete"}) >> []{...}
- (...) >> &non_templated_class_with_templated_callable_operator
- get and "/profile/"_tpath and set_by_class_constructor