Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
http server and http client in the standard library #910
This was referenced
May 4, 2018
I can understand putting in an http client for the package manager but an http server? Building a secure http server is a big project. And if its in the std lib people will use it and it will have to be supported. But an officially support http server reference project used by zig to host zig would be awesome, but I would avoid including it in the std lib.
I would also avoid including C projects directly in the std lib. One mistake in D was including Curl in the std lib, now they have to deal with Curl versioning and distributing curl libs with the application. Would be better having an official package for these kitchen sink items, then when we want to end support they can be forked off into the community (or left abandoned in git) without it affecting the std lib.
Agreed. Include a HTTP client and then everything else should come from community packages. If the community converges on a set of very popular, high quality libraries, then you pull those in and even then, for a language such as Zig you'd probably want them just "outside" of the stdlib, in set of libraries maintained by the language developers yet separate (a sort of recommended and supported libraries, but not necessarily with the same commitment for backwards compatibility as the stdlib, which generally is super strict).
The main reason is that you want to avoid the Python or Java situation where you have a ton of libraries which are either bad or completely obsolete but can't be removed.
Right now the standard library exists for 2 reasons:
So an HTTP server / client would certainly help for the first case. We can evaluate whether it belongs in std when we do the stdlib audit before 1.0.0.
If it helps - here are some languages that have HTTP either in core or standard:
I would suggest adding to the standard library a low-level http library based on RFC-7230, which defined simply the HTTP message format, basically, not semantics (e.g. meaning of HTTP verbs, headers etc. which is defined in other RFCs). This is simple and can be the foundation of higher level libraries, including http clients and servers, while still being useful on its own to accomplish the goals mentioned by @andrewrk.
I wrote a low-level HTTP library in Java (which I am thinking of translating to zig for the async support and speed) and it's not a lot of work. Higher level APIs to work with HTTP are hard to get right and most people have different preferences on what they should look like (which probably explains most languages having several different options - which is probably a good thing), hence those are better left to third-party libraries, IMHO.
This may be an unpopular position, but I have noticed that Go suffers from very weak a) websocket, b) terminal, and c) GUI packages. I realize there is a vast amount of work represented in that short sentence, but there was also an enormous amount of community interest in it, and a likewise enormous amount of community fragmentation around different half-baked solutions to these problems.
Rust has a similar fragmented set of community solutions. Everyone wants to write a parser, everyone wants to do their own async i/o, etc.
Perhaps the way to do this is to support a canonical set of packages, sort of a second-tier set of official repos that are still outside of the stdlib, but that will always be the go-to for Zig for that problem. Thinking out loud here.
Has default HTTP server build in.
Relies on external Vibe.D for HTTP support.
Its a issue that all Languages share. Any language that has a package manager tends to fragment the community because everybody wants "their" code to be popular or they disagree with the authors of other packages or ...
Look at Go ... Sometimes 20 packages that do the same thing, just in different ways, different supports ( not counting the clones with minimal changes ). Npm ... same.
Languages need to have a tighter controle over there eco system. No Raft Protocol package? Somebody can write one, that follows the language library standard. That becomes a official standard library package.
Somebody want to improve it? Commit to the official version.
Keep tight control over the resources. What makes PHP so easy? Not just the language but also the fact that all official extensions are fast, secure and well documented. Its in general the stuff outside the standard library that has issues over time. Hell, you can use 10 year old library code and it will mostly still work.
Unlike languages that rely a lot on external 3th party plugins, where your old code need to use unmaintained code or it does not work or ... and then requires rewrites or whatever issues.
Yep, lots of progress: