Hello Simon, thanks for the advice. On 22/04/07, Simon Richter <Simon.Richter@hogyros.de> wrote:
Hello,
Darren Garvey wrote:
- low-level design decisions
If possible, I'd like to see some support for embedded devices.
I couldn't think of why you'd use an embedded device for a CGI program. I've just been reading up though, I get it now. Due to the computing power/memory constraints, there are a few things
that are important in such a setting.
First, memory fragmentation is a real problem. Apache spawns new child processes with unfragmented memory maps every n requests to avoid this, however you can only do this with an MMU. Since a lot of embedded devices have none, people use pooled allocators and group related allocations together in order to minimize the impact; ideally, there'd be a way for allocations made while serving one request to use a specific allocator instance (the default, of course, being the standard new/delete allocator).
This hadn't crossed my mind. Oops. Just to clarify, when you say: '...there'd be a way for allocations made while serving one request to use a specific allocator instance', are you talking about providing such an allocator for _users_ of the library, or are you talking just about handling memory allocation internally? Related to this: it is quite unlikely that it is possible to allocate
large buffers, so allowing a way to access form form elements as a stream (before the incoming data is fully processed) would be good. One of *the* major use cases of form processing is firmware upload. The CGI needs to be able to accept these files (which can be as large as half the available system memory, so loading them into RAM is not an option), and also be able to recover if an invalid file is submitted (i.e. the CGI should be able to inspect the data as it is uploaded, and there should be an option to ignore the remainder of the file upload in case of an error so an appropriate error message can be returned).
Point taken. The ability to handle file uploads was the reason I rolled my own basic-CGI lib, a couple of years ago. It's a bit trickier with FastCGI, but not significantly so. Speaking of error messages, the header output needs to be delayed until
after processing obviously, and there needs to be a way to simply stream a file as a response.
Ideally, it all would integrate with boost's iostreams and/or asio to allow the user code to reuse as much code as possible.
Integration with Boost.Iostreams is something I've yet to get working (but I do intend to). My mentor for the SoC is Chris Kohlhoff, so integration with asio isn't a choice (actually, asio's essential to the FastCGI stuff). ;-) Regards, Darren