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

Raphters, a web framework for C

github.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Raphters, a web framework for C

#61

Post by ay »

compay wrote: post #11

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.

Luajit2 approaches C on speed [1] - and with the newly released FFI library the C is not really needed that much - so, pretty much all the work has been already done. Just use the results of it :)

[1] http://news.ycombinator.com/item?id=641313

Re: Raphters, a web framework for C

#62

Post by wladimir »

nkurz wrote: post #59
tptacek wrote: post #39

Earlier quoted context omitted.

You need to convert < into &lt;. That's the price of entry. You can't redefine the problem to "web framework that simply strips < out of inputs". Your framework would then be immediately inferior to every other framework which does output quoting.

Yes, if it was done in the framework, you'd want to have the sanitizing and allocation happen seamlessly, and you'd want the memory management to be simple as well. My confusion was why this strikes you as a significant difficulty for a framework author to set up. Certainly it's harder if you decide that you are going to work from the ground up in straight ANSI C, but there's lots of good pool memory allocators out t…

Hm good point. Built-in C string handling is much too painful for me to even consider doing a web application in C, and you have to worry about buffer overflows and memory leaks all the time. I'm so happy I don't have to do that in Python.

Then again, if you have a sane string handling library in C instead of messing around with strcpy/strcat, malloc/free and fixed-sized buffers, I guess it could be made more convenient.

so that the user would find the string creation and destruction just as seamless as in Perl or Python

If you manage to do that, please send me the link :)

Re: Raphters, a web framework for C

#63

Post by compay »

ay wrote: post #61
compay wrote: post #11

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.

Luajit2 approaches C on speed [1] - and with the newly released FFI library the C is not really needed that much - so, pretty much all the work has been already done. Just use the results of it :) [1] http://news.ycombinator.com/item?id=641313

LuaJIT is awesome but it doesn't run on as many architectures as the original Lua VM. The nice thing about a framework in C is that you can install it anywhere it compiles, and if you stick to ANSI C like Lua does then it compiles pretty much anywhere, like Lua itself.

Re: Raphters, a web framework for C

#64

Post by roel_v »

roel_v wrote: post #5
rbranson wrote: post #4

This 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.

Well yes it should have been

    response_set_status(handle, 200);
My point was that the syntax in the example was C++.

Re: Raphters, a web framework for C

#65

Post by ay »

compay wrote: post #63
ay wrote: post #61

Earlier quoted context omitted.

Luajit2 approaches C on speed [1] - and with the newly released FFI library the C is not really needed that much - so, pretty much all the work has been already done. Just use the results of it :) [1] http://news.ycombinator.com/item?id=641313

LuaJIT is awesome but it doesn't run on as many architectures as the original Lua VM. The nice thing about a framework in C is that you can install it anywhere it compiles, and if you stick to ANSI C like Lua does then it compiles pretty much anywhere, like Lua itself.

Agree, just x86 and x86_64 - though realistically, is there a lot of usage of other platforms for high-performance servers ?

And if the server is not high-performing, mongrel2 + $something can be a very good choice. (And has a more liberal license).

But of course, the tastes differ - so the more, the merrier. as soon as the folks do not get pwned.

Re: Raphters, a web framework for C

#66

Post by compay »

ay wrote: post #65
compay wrote: post #63

Earlier quoted context omitted.

LuaJIT is awesome but it doesn't run on as many architectures as the original Lua VM. The nice thing about a framework in C is that you can install it anywhere it compiles, and if you stick to ANSI C like Lua does then it compiles pretty much anywhere, like Lua itself.

Agree, just x86 and x86_64 - though realistically, is there a lot of usage of other platforms for high-performance servers ? And if the server is not high-performing, mongrel2 + $something can be a very good choice. (And has a more liberal license). But of course, the tastes differ - so the more, the merrier. as soon as the folks do not get pwned.

I'm thinking of small devices like wireless routers, phones and maybe even wristwatches. I like the idea of having a full stack framework for web apps, served locally on a tiny device. You could reuse a lot of code that way and at least for phones, potentially avoid some of the cost of having a native app with totally different code from your web app.

But yeah, LuaJIT recently added support PPC and soon will add ARM, so point well taken - to do what I'm thinking of, it may not really be necessary to have anything in C.

Re: Raphters, a web framework for C

#69

Post by DanWaterworth »

nkurz wrote: post #59
tptacek wrote: post #39

Earlier quoted context omitted.

You need to convert < into &lt;. That's the price of entry. You can't redefine the problem to "web framework that simply strips < out of inputs". Your framework would then be immediately inferior to every other framework which does output quoting.

Yes, if it was done in the framework, you'd want to have the sanitizing and allocation happen seamlessly, and you'd want the memory management to be simple as well. My confusion was why this strikes you as a significant difficulty for a framework author to set up. Certainly it's harder if you decide that you are going to work from the ground up in straight ANSI C, but there's lots of good pool memory allocators out t…

You could just have a linked list of memory allocations that get freed at the end of the request.

Re: Raphters, a web framework for C

#70

Post by DanWaterworth »

tptacek wrote: post #38
JoachimSchipper wrote: post #30

Earlier quoted context omitted.

Something like evhttp also has the benefit that you can have more than one request "in flight". FastCGI can theoretically do this, but almost no implementation supports it - and it makes e.g. writing a simple chat server much easier (one process, one thread, tons of connections, data in memory.)

The downside to doing evhttp is that he'll have to write his own request parsing (I think he's relying on Apache/CGI to do that for him now). But if you're going to do a C web framework (and... really? you sure about that?), that's probably how you should do it.

Request parsing is no big deal, I've already written a json parser/generator for this project (though it's in a separate project atm).
Post reply on HN