"After a long break from working on my hobby operating system, I finally got back into it and finished a very important milestone"
This is a sign of great engineering. Code gets foreign code after some time of not being in it. If you easily can pick it up again, it is a sign that you've written maintainable and understandable code, also for others.
Very cool! Why was and the entire networking stack straight forward, but not HTTP (and TCP)? Could you take inspiration form other projects for things like DNS?
Up to TCP most protocols are very straight forward, atleast getting them to work semi reliable. But then TCP explodes in complexity with all the state management and possible paths a connection can take.
HTTP is mostly annoying because of all the text parsing :D
Yeah...HTTP/1 is one of those weird cases where the older protocol is considerably more difficult to implement correctly than the newer ""more complex"" standard. This is especially true if you want your server to work with they myriad of questionably compliant clients out in the world.
HTTP/3 might have been easier, and using QUIC+HTTP/3 in your hobby OS is a fun flex :)
I don’t think that http/3 is easier to implement than http/1.1 especially since h3 is stateful where http/1.1 is not. Especially not when everything should be working correctly and securely because the spec does not always tell about these things. Oh and multiplexing is quite a hard thing to do especially when you are also dealing with a state machine and each of your clients can be malicious.
I can't speak to http/3 (I haven't tried to impl it), but I can say that a bare-bones http/2 is very easy to implement because it doesn't try to pretend to be prose.
Because, you can iterate on the spec with all the stakeholders without ever writing a line of business logic. There are tools which can create a dummy web server from the specification and you can build clients without implementing business logic. I thought the advantages of spec-first development are obvious but I hope I helped.
Thanks. The advantages of having a spec is obvious to me as well. I'm just not sure why building business logic that generates the spec (that generates the client) is a bad idea. That way you still have a single source of truth, and a spec.
"After a long break from working on my hobby operating system, I finally got back into it and finished a very important milestone"
This is a sign of great engineering. Code gets foreign code after some time of not being in it. If you easily can pick it up again, it is a sign that you've written maintainable and understandable code, also for others.
Great website, massive rabbit hole I didn't know existed. There's a verified Ada/SPARK OS in there...
Very cool! Why was and the entire networking stack straight forward, but not HTTP (and TCP)? Could you take inspiration form other projects for things like DNS?
Up to TCP most protocols are very straight forward, atleast getting them to work semi reliable. But then TCP explodes in complexity with all the state management and possible paths a connection can take.
HTTP is mostly annoying because of all the text parsing :D
Yeah...HTTP/1 is one of those weird cases where the older protocol is considerably more difficult to implement correctly than the newer ""more complex"" standard. This is especially true if you want your server to work with they myriad of questionably compliant clients out in the world.
HTTP/3 might have been easier, and using QUIC+HTTP/3 in your hobby OS is a fun flex :)
httpdito http://canonical.org/~kragen/sw/dev3/server.s implements HTTP/1.0 GET in about 320 machine instructions, and I haven't yet found a questionably compliant client that doesn't work with it. Writeup in http://canonical.org/~kragen/sw/dev3/httpdito-readme.
I don’t think that http/3 is easier to implement than http/1.1 especially since h3 is stateful where http/1.1 is not. Especially not when everything should be working correctly and securely because the spec does not always tell about these things. Oh and multiplexing is quite a hard thing to do especially when you are also dealing with a state machine and each of your clients can be malicious.
I can't speak to http/3 (I haven't tried to impl it), but I can say that a bare-bones http/2 is very easy to implement because it doesn't try to pretend to be prose.
You should add OpenAPI generation. So that basically the endpoint /openapi.json is auto-generated.
Like most thing in web development, this is backwards. Applications should be generated from the spec, not the other way around.
Care to explain the advantage of starting off with the spec rather than with code?
Because, you can iterate on the spec with all the stakeholders without ever writing a line of business logic. There are tools which can create a dummy web server from the specification and you can build clients without implementing business logic. I thought the advantages of spec-first development are obvious but I hope I helped.
Thanks. The advantages of having a spec is obvious to me as well. I'm just not sure why building business logic that generates the spec (that generates the client) is a bad idea. That way you still have a single source of truth, and a spec.
related - someone should take a stab at actually finishing this :) https://github.com/drogonframework/drogon/issues/988
[flagged]