Hello, Darren Garvey wrote:
- low-level design decisions
If possible, I'd like to see some support for embedded devices. 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). 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). 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. Simon