It would be neat to see how you could possibly hook Lua into this to give you some of the flexibility of a dynamic language with the speed and small footprint of a (mostly) C app. I've been thinking of working on something like that for a while but unfortunately my C skills need a lot more work before I'd be comfortable tackling it.
Raphters, a web framework for C
11–20 of 70 posts
Re: Raphters, a web framework for C
#12This framework does almost nothing. I don't see the point of it.
Re: Raphters, a web framework for C
#13This is neat. Honestly, in addition, I'd like to see something like Rack for C. The "gateway interfaces" for C are too implementation-specific (CGI, FastCGI, SCGI, web server extensions/modules, etc). It would be something more abstract that would run on-top of a web server interface. void application_main(web_request *request, web_response *response) { char body[1024]; snprintf(body, sizeof(body), "Hello, %s", reque…
Rather: response_set_status(200); response_set_header("Content-Type", "text/html"); response_write(body); response_end(); The awkwardness of which, to me, demonstrates the superiority of C++ in this regard.
You're only a couple function pointers away from the syntactic sugar of the -> operator.
Re: Raphters, a web framework for C
#14Earlier quoted context omitted.
Rather: response_set_status(200); response_set_header("Content-Type", "text/html"); response_write(body); response_end(); The awkwardness of which, to me, demonstrates the superiority of C++ in this regard.
That implies some global state somewhere being updated, and now you've given up on threading. This may be OK, but it's still dangerous and leaky even if you give up on threading. There are various solutions that still allow you to pass a set of closures without being particularly more ugly than anything else is in C, for instance, see http://library.gnome.org/devel/gobject/stable/chapter-signal... . C++ still ends up…
They don't have to be global state - they can be updating thread local state, for example, in what is essentially dynamic scope. Depending on the OS, the efficiency of such TLS accesses can be quite good - on Linux, for example, it's just an extra pointer indirect or two with a segment selector (assuming the code is statically linked; it's very slightly more expensive in a solib).
Re: Raphters, a web framework for C
#15Earlier quoted context omitted.
That implies some global state somewhere being updated, and now you've given up on threading. This may be OK, but it's still dangerous and leaky even if you give up on threading. There are various solutions that still allow you to pass a set of closures without being particularly more ugly than anything else is in C, for instance, see http://library.gnome.org/devel/gobject/stable/chapter-signal... . C++ still ends up…
You're right, web developers already write software with all the security of a colander. You can go one of two ways, 1.) you can devise a language that can't express an insecure application or 2.) you can teach people about security. I know which option I prefer.
I assume you mean #2? Because here we are in year, oh, 17 or 18 or so of web development give or take a couple of years and that's worked out so well, hasn't it?
It's a beautiful sentiment. It hasn't worked. Handing them new vectors to screw up in is not going to solve the problem.
It also doesn't matter. Hand a developer a tool that requires them to continuously pay attention to an issue and no matter how good they are, at some point they will slip, because they're human. We've tried "teach them about security" a couple hundred times, maybe it's time we try "devise a language that can't trivially express an insecure application". C will not be the language that implements that, it completely lacks any of the necessary primitives, by design.
Re: Raphters, a web framework for C
#16Earlier quoted context omitted.
That implies some global state somewhere being updated, and now you've given up on threading. This may be OK, but it's still dangerous and leaky even if you give up on threading. There are various solutions that still allow you to pass a set of closures without being particularly more ugly than anything else is in C, for instance, see http://library.gnome.org/devel/gobject/stable/chapter-signal... . C++ still ends up…
You're right, web developers already write software with all the security of a colander. You can go one of two ways, 1.) you can devise a language that can't express an insecure application or 2.) you can teach people about security. I know which option I prefer.
Overly reductive. There is an actual security benefit to using environments that minimize memory corruption. Educating devs helps, but educated devs do not reliably avoid memory corruption.
Re: Raphters, a web framework for C
#17Earlier quoted context omitted.
That implies some global state somewhere being updated, and now you've given up on threading. This may be OK, but it's still dangerous and leaky even if you give up on threading. There are various solutions that still allow you to pass a set of closures without being particularly more ugly than anything else is in C, for instance, see http://library.gnome.org/devel/gobject/stable/chapter-signal... . C++ still ends up…
They don't have to be global state - they can be updating thread local state, for example, in what is essentially dynamic scope. Depending on the OS, the efficiency of such TLS accesses can be quite good - on Linux, for example, it's just an extra pointer indirect or two with a segment selector (assuming the code is statically linked; it's very slightly more expensive in a solib).
Touche. It's still an API design that's going to prove problematic, though.
Re: Raphters, a web framework for C
#18This framework does almost nothing. I don't see the point of it.
Reinventing the wheel for lulz...
Re: Raphters, a web framework for C
#19Interesting, but very minimal. It's basically a wrapper around FCGI (meaning it's doing the old-school "pull request data out of environment variables" thing) with a linked list of regexes matching handlers. That's not nothing; "registered list of regexes matching handlers" is a proven good model for web frameworks and it's handy to have.
On the other hand, if I was going to release a web framework, I might do more to abstract request variables (provide a params hash like Rails, or a Rack-style request hash). Also: I'd probably build it on libevent's evhttp instead of demanding that users plug my C code into FCGI.
Re: Raphters, a web framework for C
#20This is neat. Honestly, in addition, I'd like to see something like Rack for C. The "gateway interfaces" for C are too implementation-specific (CGI, FastCGI, SCGI, web server extensions/modules, etc). It would be something more abstract that would run on-top of a web server interface. void application_main(web_request *request, web_response *response) { char body[1024]; snprintf(body, sizeof(body), "Hello, %s", reque…
As an illustration of why C kind of sucks for web apps, that code is obviously insecure† (it's reflected XSS). To get around that while preserving natural syntax, you want:
char *hsafe(const char *input);
Maybe you can do an arena for each connection, so it's:
char *hsafe(request_t *r, char *str)
† In an admittedly artificial way.