Re: [boost] [GSoC] Opinions and suggestions for improving CGI library

Subject: Re: [boost] [GSoC] Opinions and suggestions for improving CGI library
From: Eugene Wee (crystalrecursion_at_[hidden])
Date: 2009-03-28 16:11:12

Hi Phil,

Thank you for your feedback :)

Web applications have persistent data associated with sessions, but they
> also have persistent data associated with e.g. a username or page, etc.  I
> would think that IFF the framework provides a good way to access cookies,
> form variables etc AND handle the data storage (database,
> Boost.Serialisation, Boost.Interprocess) THEN the user should be allowed to
> plumb these together as they wish: there are many possible combinations with
> no "one size fits all".

The CGI library already provides ways to access cookies and form variables.
I think that, in general, data storage is separate from this library.
Certainly, with say a database library and what is already implemented, a
user can implement her/her own session handling, but the point is to provide
a convenient interface to do so rather than require users to reinvent it.
Since data storage is separate, I view data storage types as something that
should be pluggable.

 multipart/form-data is basically MIME, so providing a library that can also
> be used more generally would be useful.  It would be a shame to implement a
> MIME parser and then to hide it as an implementation detail inside another
> library.

I agree, but I am not sure if the GSoC timeframe will allow me to be so
general and yet work on the other two aspects that I wish to improve for the
CGI library. However, this could be a precursor to such a library (perhaps
for GSoC 2010, haha).

I have previously implemented a basic multipart/form-data parser using
> "traditional" string manipulation (i.e. find, substr etc).  It's not clear
> to me that Boost.Spirit offers a significant benefit for this task.
>

Certainly, I would like to keep things simple, and the main point is that
the current use of regular expressions is overly complex and difficult to
read and maintain. Should I then modify my proposal to aim to investigate
the best way of re-implementing this part of the CGI library, and then
perform the re-implementation?

Thanks,
Eugene