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