Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

Post reply on HN
Print view View original

211–220 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#211

Post by jbverschoor »

ahartmetz wrote: post #36
saba2008 wrote: post #15

Earlier quoted context omitted.

HTTP/1 simplicity comes not from text nature, but from it's clear concept and limited functionality. At core, it's just request-reply + key-value metadata. Whenever it's text, or binary, it does not matter much. But writing HTTP/2 frame types in letters would not make them any easier to understand.

There are also keep-alive, caching (a big topic), chunked transfer encoding, header parsing peculiarities, and authentication in HTTP. The combination of these creates some nice opportunities for implementation bugs. Source: have worked on a client-side implementation. Now, HTTP/2 isn't even conceptually simple, I agree about that... it seems ugly.

That came with http/1.1 ;-)

Re: Althttpd: Simple webserver in a single C file

#212

Post by vidarh »

tyingq wrote: post #201
vidarh wrote: post #197

Earlier quoted context omitted.

I ran a webmail service with 2m users that forked and exec'd a CGI for every request 20 years ago. 20 year old hardware was already fast enough that we were usually IO bound on the storage backend rather than constrained by the (much cheaper) frontends. Forking for every request is slow, sure. But if your code is written with it in mind it's faster than most people might expect, and most people never get to a scale w…

"I ran a webmail service with 2m users that forked and exec'd a CGI for every request" Yes, but that met expectations of that time period, and expectations for a webmail service. I'm curious if you also forked for every static asset...that's what this setup appears to do. I just don't see the benefit of mysql choosing to use this today. It works, but there are other minimal http servers that would be just as simple,…

Performance expectations were if anything for the most part tighter than what people tend to get away with today. People hadn't gotten used to slow dynamic sites yet.

We didn't fork for for every static asset, but the vast majority of overall requests were dynamic past the initial pageload, so the vast majority of requests resulted in fork.

In terms of benefits, the simplicity is attractive. It's an approach that is in general quite resilient to errors.

Re: Althttpd: Simple webserver in a single C file

#213

Post by sgbeal »

networked wrote: post #166
henvic wrote: post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

Fossil has enough wiki and theming features to power a customized website and to let you edit its contents in the browser. I've joked that Fossil SCM is secretly "Fossil CMS". My personal website, https://dbohdan.com/ , is powered by Fossil. A year ago I was shopping for a wiki engine, didn't love any I looked at, and realized I could try something I was already familiar with: Fossil. It did take a few hacks to make…

> The wiki lacks category ...

Just FYI: we recently improved the internals to be able to add propagating tags to wiki pages[1], so it will eventually be possible to use those to categorize/group your wiki pages. What's missing now is UIs which can make use of that feature. The CLI tag command can make use of them, but that doesn't help your UI much.

> ... and transclusion features

For the wiki it seems unlikely to me that transclusion will ever be a thing. It can hypothetically be done with the embedded docs feature if the fossil binary is built with "th1-docs" support, but, alas, we can't currently support propagating tags on file-level content. (i have an idea how it might be integrated, but figuring out whether or not it internally makes sense requires trying it out (and that doesn't have a high priority).)

[1] https://fossil-scm.org/forum/forumpost/3d4b79a3f9?t=h

Re: Althttpd: Simple webserver in a single C file

#214

Post by chousuke »

user-the-name wrote: post #174
azernik wrote: post #148

Earlier quoted context omitted.

Representing the history more accurately is not a useful design goal

Why not? I do not see any reason to have a history at all for anything except to be able to go back to a specific version to track down a problem. Inaccurate history makes that less useful.

Typo commits and the usual iteration during development isn't "accurate history". Noise in commit logs provides negative value.

Ideally, each commit should be something that you could submit as a stand-alone patch to a mailing list; whether it's a single commit that was perfect from the get-go or fifty that you had to re-order and rewrite twenty times does not matter at all; the final commit message should contain any necessary background information.

It would be needlessly restrictive to prevent users from making intermediate commits if that helps their workflow: I want to be able to use my source-code management tool locally in whichever way I please and what you see publicly does not need to have to have anything to do with my local workflow. Thus, being able to "rewrite history" is a necessary feature.

Re: Althttpd: Simple webserver in a single C file

#215

Post by sgbeal »

systems wrote: post #169
henvic wrote: post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

long long long time ago Fossil destroyed code for Zed Shaw And since that day, not one looked at Fossil the same way, at least not the same way they looked at git https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... I can't tell for sure how much of impact this had on fossil's adoption, its hard to beat git no matter how good you are, but I think it was a bit hit

> long long long time ago Fossil destroyed code for Zed Shaw

1) No, it didn't. Please read the part of the thread after Zed's initial panic attack.

2) To the best of our[1] knowledge, fossil itself has never caused a single byte of data loss. When fossil checks in new data, it reads that data back (in the same SQL transaction the data was written in) to ensure than it can read what it wrote with 100% fidelity, so it's nearly impossible to get corrupted data into fossil without going into the db and massaging it by hand. People have lost data by storing their only copy of a repository on failing/failed storage or on a network drive, but no software can protect against hardware failure and nobody in their right mind tries to maintain an active sqlite db over a network drive (plenty of people do it, despite the repeated warnings of anyone who knows anything about sqlite, and they have only themselves to blame when it goes pear shaped). Fossil makes syncing to/from a remote copy absolutely trivial, so any failure to regularly sync copies to a backup is end-user error.

[1] = the fossil developers.

Re: Althttpd: Simple webserver in a single C file

#216

Post by pdimitar »

xyzzy_plugh wrote: post #206
pdimitar wrote: post #194

Earlier quoted context omitted.

I appreciate the different approaches and I'm grateful for the info (and the opinionated take) right from the source. Thank you. In terms of Git and the usual commercial SCM practices, I'm speaking empirically. Everywhere I worked in a team, leaders and managers wanted main branch's history to be a bird's-eye view, to have every commit fully build in CI/CD, and be able to find who introduced a problem (admittedly thi…

We probably use the tools differently. I squash minor commits in my local branch, so I never want the review system squashing branches. If I put a branch for review, it is a series of patches which should be applied as-is. See the kernel mailing list and associated patch sets for the sort of thing I mean. I frequently use git rebase in interactive mode to rearrange and curate my commits to form whatever narrative I'm…

We definitely do use tools differently.

Not looking to pick a fight here, mind you, but the Linux kernel is hardly a representative demonstration oh how to consume Git out there in the wild.

The way you describe your usage it already seems you kinda sorta do your own squashed commits, only you want several of them get merged into the main branch, not just one. So you're still rewriting history a bit, no?

Re: Althttpd: Simple webserver in a single C file

#217

Post by JoeQuery »

metalliqaz wrote: post #178
systems wrote: post #169

Earlier quoted context omitted.

long long long time ago Fossil destroyed code for Zed Shaw And since that day, not one looked at Fossil the same way, at least not the same way they looked at git https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... I can't tell for sure how much of impact this had on fossil's adoption, its hard to beat git no matter how good you are, but I think it was a bit hit

from the linked thread: > I just cloned your repo. Everything is working fine. Breath, Zed. seems like he panicked and made it worse, then rage-quit

It's been a few years but my one and only interaction with Zed via an email exchange showed me he was quite unstable and prone to outbursts. Never meet your heroes, they say.

Re: Althttpd: Simple webserver in a single C file

#218

Post by pdimitar »

brundozer wrote: post #142
pdimitar wrote: post #100

Earlier quoted context omitted.

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

I agree with you that such a commit has nothing to do in the main branch. But it has nothing it do in any branch that is shared with anyone either. Git has enough ways to keep your own history clean at all times to not require a hack like squash PRs to compensate the lack of discipline of a team. With squash PRs you lose so much valuable information that it gets impossible to use commands like bisect or to have a pro…

I agree that you lose the benefit of a direct bisect but this is usually shrugged off with "you can go to the PR and inspect the commits one by one" which, while not ideal, is deemed a good tradeoff if you want your main branch to only contain big commits each laser-focused on one feature or bug.

As I replied to @SQLite above, I am not saying this is the optimal state of affairs -- not at all. But it's what is required everywhere I ever worked for 19.5 years (and similar output was desired when we worked with CVS and Subversion and it was harder to achieve there).

But I'll disagree this is lack of discipline. It's not that at all. It's a compromise between programmers, managers/supervisors, CTOs / directors of engineering, and release engineers. They want a bird's-eye view of the project in the main branch.

Re: Althttpd: Simple webserver in a single C file

#220

Post by pdimitar »

dimitrios1 wrote: post #182
pdimitar wrote: post #100

Earlier quoted context omitted.

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

Consider editing. Yes, a paper goes through revisions, which are holistic, and represent one iteration to the next. But in between those revisions, you can see markups, and editor notes as to why a change was performed. Sometimes those insights are just as useful as the packaged whole.

Everybody who ever wrote their own diffing program has considered that and that's not the problem. The problem is how does this approach scale in a repo with 50+ contributors? It doesn't, sadly.
Post reply on HN