[Boost][ProgramOptions] Interest in a CGI parameters parser?
Hello, Yesterday I had to write a program that compiles 2 forms of executables: a standalone version that takes its parameters from the command line, and another one that serves as a CGI program and thus takes exactly the same parameters but from stdin (POST method). I naturally chose Boost.ProgramOptions for the first one, and did the job by myself for the second one. I finally realized that I was doing fundamentally the same thing as what a ProgramOptions parser basically does: parsing a name=value series of variables, checking unknown values, assign them to variables, etc... plus a few formatting work to handle URL format specificities. So in the end I was wondering if a "cgi_query_parser" would be appreciated as an addition to the parsers already present in Boost.ProgramOptions? I can directly see the benefits inside my own program since the 2 versions would only differ on one line of code.
From a more general point of view, it could be a simple way to have a CGI support somewhere in Boost.
If such a thing can be interesting, I can take a few time to implement it. Regards Bruno
On Fri, 04 Apr 2008 18:03:00 +0200, Bruno Lalande <bruno.lalande@gmail.com> wrote:
[...]So in the end I was wondering if a "cgi_query_parser" would be appreciated as an addition to the parsers already present in Boost.ProgramOptions? I can directly see the benefits inside my own program since the 2 versions would only differ on one line of code.
From a more general point of view, it could be a simple way to have a CGI support somewhere in Boost.
If such a thing can be interesting, I can take a few time to implement it.
I'm interested in a more general approach to extend Boost.ProgramOptions with new parsers. Then you could add a CGI query parser while I could add a parser which reads configuration data from JSON files. Then however Boost.ProgramOptions would need to support something more sophisticated than key=value pairs. I'm not sure if this can be easily generalized? Boris
I'm interested in a more general approach to extend Boost.ProgramOptions with new parsers. Then you could add a CGI query parser while I could add a parser which reads configuration data from JSON files. Then however Boost.ProgramOptions would need to support something more sophisticated than key=value pairs. I'm not sure if this can be easily generalized?
Maybe an extension facility for ProgramOptions parsers could be made. I don't know yet exactly how this part of the library is designed and how easy it is to extend it. My approach would thus be to implement what I've proposed by first merely making another whole parser. Then I'll have a better sight and I can decide if we can go further towards genericity and extension features. However, the extension possibilities of the library are already at a good level due to its separation into 3 parts: descriptions, parsing and storage. not sure if the parsing parts really has to be even more generic... As long as JSON has a hierarchical structure, wouldn't it be better for you to use the future property_tree library? Bruno
Bruno Lalande wrote:
I'm interested in a more general approach to extend Boost.ProgramOptions with new parsers. Then you could add a CGI query parser while I could add a parser which reads configuration data from JSON files. Then however Boost.ProgramOptions would need to support something more sophisticated than key=value pairs. I'm not sure if this can be easily generalized?
Maybe an extension facility for ProgramOptions parsers could be made. I don't know yet exactly how this part of the library is designed and how easy it is to extend it. My approach would thus be to implement what I've proposed by first merely making another whole parser. Then I'll have a better sight and I can decide if we can go further towards genericity and extension features. However, the extension possibilities of the library are already at a good level due to its separation into 3 parts: descriptions, parsing and storage. not sure if the parsing parts really has to be even more generic...
I don't either. A parser is basically a function, which anybody can call. One does not have to register a parser with the rest of library in any way.
As long as JSON has a hierarchical structure, wouldn't it be better for you to use the future property_tree library?
That's a good question. I actually wondered about using hierarchical storage for program_option, possibly based on property_tree. Nothing concrete at this point. - Volodya
On Sat, 05 Apr 2008 11:45:50 +0200, Vladimir Prus <ghost@cs.msu.su> wrote:
[...]
As long as JSON has a hierarchical structure, wouldn't it be better for you to use the future property_tree library?
To which Boost library does property_tree belong? Is it Boost Property Map? I found a file propert_tree_rev5.zip in the Vault but it has been uploaded two years ago?
That's a good question. I actually wondered about using hierarchical storage for program_option, possibly based on property_tree. Nothing concrete at this point.
Yes, that's what I meant. Even if I can create my own parse function it won't help me if the file format I parse can't be represented by the storage used by Boost.ProgramOptions. But I guess the storage can't be as much generalized that someone who wants to use any file format X can create a parser for Boost.ProgramOptions, too. Boris
As long as JSON has a hierarchical structure, wouldn't it be better for you to use the future property_tree library?
To which Boost library does property_tree belong? Is it Boost Property Map? I found a file propert_tree_rev5.zip in the Vault but it has been uploaded two years ago?
It will be a library on its own. I'm not really aware of the whole story but basically it has been started some time ago and after having been in standby mode during a while, it has restarted recently: http://www.nabble.com/Status-of-the-Boost.Property_tree-library-td15977780.h...
That's a good question. I actually wondered about using hierarchical storage for program_option, possibly based on property_tree. Nothing concrete at this point.
Yes, that's what I meant. Even if I can create my own parse function it won't help me if the file format I parse can't be represented by the storage used by Boost.ProgramOptions. But I guess the storage can't be as much generalized that someone who wants to use any file format X can create a parser for Boost.ProgramOptions, too.
Indeed, a few glue code between program_options and property_tree library would be a very neat solution, I completely agree with this idea. Let's keep it in mind until property_tree is released. For the storage problem, why not merely insert some dots into the variable names without changing anything to the storage model itself: you would query variables["object.subobject.field"] to access a nested field. Bruno
I thought I'd mention... Along with config macro defs I started extracting all the Config rewrite macros < http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig> into a separate library <http://svn.boost.org/trac/boost/browser/sandbox/predef>.
If you're rewriting the config macros, one change I'd strongly recommend is a strict separation between macros that are to be defined by the users and macros that are defined in config.hpp. If the documentation says that a macro should be defined by users, then it should not be defined by any of the boost libraries. 2008/4/4, Bruno Lalande <bruno.lalande@gmail.com>:
Hello,
Yesterday I had to write a program that compiles 2 forms of executables: a standalone version that takes its parameters from the command line, and another one that serves as a CGI program and thus takes exactly the same parameters but from stdin (POST method). I naturally chose Boost.ProgramOptions for the first one, and did the job by myself for the second one. I finally realized that I was doing fundamentally the same thing as what a ProgramOptions parser basically does: parsing a name=value series of variables, checking unknown values, assign them to variables, etc... plus a few formatting work to handle URL format specificities.
So in the end I was wondering if a "cgi_query_parser" would be appreciated as an addition to the parsers already present in Boost.ProgramOptions? I can directly see the benefits inside my own program since the 2 versions would only differ on one line of code.
From a more general point of view, it could be a simple way to have a CGI support somewhere in Boost.
If such a thing can be interesting, I can take a few time to implement it.
Regards Bruno _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- In god we trust. Thierno Camara
Bruno Lalande wrote:
Hello,
Yesterday I had to write a program that compiles 2 forms of executables: a standalone version that takes its parameters from the command line, and another one that serves as a CGI program and thus takes exactly the same parameters but from stdin (POST method). I naturally chose Boost.ProgramOptions for the first one, and did the job by myself for the second one. I finally realized that I was doing fundamentally the same thing as what a ProgramOptions parser basically does: parsing a name=value series of variables, checking unknown values, assign them to variables, etc... plus a few formatting work to handle URL format specificities.
So in the end I was wondering if a "cgi_query_parser" would be appreciated as an addition to the parsers already present in Boost.ProgramOptions? I can directly see the benefits inside my own program since the 2 versions would only differ on one line of code.
From a more general point of view, it could be a simple way to have a CGI support somewhere in Boost.
If such a thing can be interesting, I can take a few time to implement it.
I must admit I have zero knowledge of CGI. As soon as it actually makes sense to parse it using program_options, and there's no some fundamental mismatch, I'd be happy to have CGI parser included. Thanks, Volodya
I must admit I have zero knowledge of CGI. As soon as it actually makes sense to parse it using program_options, and there's no some fundamental mismatch, I'd be happy to have CGI parser included.
Good :-) I'll work on that and let you know when it's done. Bruno
Hi Vladimir, Here is a first version of the CGI query parser, with a test suite. Could you please take a look and tell me if all sounds good for you till this point? I will also write a quick doc to integrate to the existing "Specific parsers" section. I have a few questions: - should I implement a "parse_cgi_query" helper function as it is the case for the other parsers? - what should exactly be put into the "original_tokens" member of the "option" class? The whole query, only the specific part the option comes from, or something else? - do I have to add BOOST_PROGRAM_OPTIONS_DECL to every class declaration? Thanks Bruno
On Apr 5, 2008, at 5:47 AM, "Bruno Lalande" <bruno.lalande@gmail.com> wrote:
I must admit I have zero knowledge of CGI. As soon as it actually makes sense to parse it using program_options, and there's no some fundamental mismatch, I'd be happy to have CGI parser included.
Good :-) I'll work on that and let you know when it's done.
Bruno _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I was recently looking at doing something like this. I am interested in what you come up with. Chris
Hi Christopher,
I was recently looking at doing something like this. I am interested in what you come up with.
Thanks for your interest. FYI, if you need it right now, you can already use the first version I've posted in the previous mail. If I take the "getting started" example in the docs, the only thing you have to change once included my header is the store() line : po::store(po::cgi_query_parser().options(desc).run(), vm); Regards Bruno
Hi Volodya, Here is a new version of the CGI query parser, that can now handle CGI queries encoded using the multipart format, with an updated test suite. I also attach a patch for overview.xml, that will add the documentation of this parser inside the "Specific parsers" section. If you're not knowledgeable about CGI, the doc will help you to get the general idea and will show you the relation between CGI and the Program_Options library. This patch can be applied on the current trunk version (rev 45220). I didn't have any answer to the few questions I asked in the first submission, did I miss something? Regards Bruno
Thanks, After playing with it a little bit, it seems this won't work for me out of the box since I am using FastCGI. FastCGI seems to store the environment variable internally and also manage the i/o, so that getenv and std::cin won't work. You may want to consider supporting FastCGI, since it is important for CGI programs that maintain state between calls, such as database connections. Chris On Fri, Apr 25, 2008 at 4:28 AM, Bruno Lalande <bruno.lalande@gmail.com> wrote:
Hi Christopher,
I was recently looking at doing something like this. I am interested in what you come up with.
Thanks for your interest. FYI, if you need it right now, you can already use the first version I've posted in the previous mail. If I take the "getting started" example in the docs, the only thing you have to change once included my header is the store() line :
po::store(po::cgi_query_parser().options(desc).run(), vm);
Regards
Bruno _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi,
Thanks, After playing with it a little bit, it seems this won't work for me out of the box since I am using FastCGI. FastCGI seems to store the environment variable internally and also manage the i/o, so that getenv and std::cin won't work. You may want to consider supporting FastCGI, since it is important for CGI programs that maintain state between calls, such as database connections. Chris
Yep you're right, FastCGI has to be supported since it's quite widely used now. I'm not well informed yet on what it is in regards to "classic" CGI and didn't know it was technically that different. I'll work on this. Thanks for having given a try! Bruno
Hi Chris, 2008/5/13 Chris Weed <chrisweed@gmail.com>:
Thanks, After playing with it a little bit, it seems this won't work for me out of the box since I am using FastCGI. FastCGI seems to store the environment variable internally and also manage the i/o, so that getenv and std::cin won't work. You may want to consider supporting FastCGI, since it is important for CGI programs that maintain state between calls, such as database connections. Chris
There is work being done on a FastCGI/CGI library too ( http://cgi.sf.net ). I'm able to pick up its development again in a couple of weeks but for now FastCGI support is included only for linux/apache. If you're looking for production code *right now* then you might want to look at libfastcgi ( http://cryp.to/libfastcgi/ ) or cgicc ( http://www.gnu.org/software/cgicc/ ). Regards, Darren
Sent from my iPhone On May 13, 2008, at 12:22 PM, "Darren Garvey" <darren.garvey@gmail.com> wrote:
Hi Chris,
2008/5/13 Chris Weed <chrisweed@gmail.com>:
Thanks, After playing with it a little bit, it seems this won't work for me out of the box since I am using FastCGI. FastCGI seems to store the environment variable internally and also manage the i/o, so that getenv and std::cin won't work. You may want to consider supporting FastCGI, since it is important for CGI programs that maintain state between calls, such as database connections. Chris
There is work being done on a FastCGI/CGI library too ( http://cgi.sf.net ). I'm able to pick up its development again in a couple of weeks but for now FastCGI support is included only for linux/apache.
If you're looking for production code *right now* then you might want to look at libfastcgi ( http://cryp.to/libfastcgi/ ) or cgicc ( http://www.gnu.org/software/cgicc/ ).
Regards, Darren _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/m
Thanks for the heads up on this. I am using cgicc w/ fastcgi currently. I hacked up the previously discussed cgi parser to take the cgicc CgiInput* in its constructor and call its getenv and read instead of global getenv and std::cin.read. It would be nice to have a way to get fastcgi environment into the program options parser. That I haven 't done. Chris
participants (7)
-
Boris -
Bruno Lalande -
Chris Weed -
Christopher Weed
-
Darren Garvey -
thierno camara -
Vladimir Prus