Re: [boost] [soc07][cgi] RFC: use-cases/scope

From: Darren Garvey (lists.drrngrvy_at_[hidden])
Date: 2007-04-22 18:34:15

Hello Simon, thanks for the advice.

On 22/04/07, Simon Richter <Simon.Richter_at_[hidden]> 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