Menu
▾
▴
cpp-netlib-devel
|
From: Dean M. B. <mik...@gm...> - 2010-02-11 14:26:10
|
I was thinking about this a little and thought it would be cool to have a collection of utilities of commonly-performed actions that others might find useful in the library. Off the top of my head I find that these would be cool functions/mini-libraries to have: * MIME Parser (Marshall Clow has a cool one worthy of more attention and discussion, hopefully he merges it into cpp-netlib in time for BoostCon 2010 ;) ). * Form encoding/decoding (for HTTP clients/servers to handle HTML form encoded data) * Query string encoding/decoding (for GET queries) * Base64 stream/string encoding/decoding (for Binary data) * URI pattern-based dispatch (ala Rails, or Django/Tornado) I find myself wanting to write these myself or at least using them when I write programs that use cpp-netlib. Simple things like for HTTP server based applications I want to be able to parse a list of parameters (remembering what Jeroen was proposing to do with the URI parser one time). Any takers? It would be cool if we had these in the library before May where I will be presenting the library and the techniques used in the library at a high level. ;) Hope this helps and I hope to hear from you guys soon too! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-02-11 16:34:37
Attachments:
dispatcher.hpp
|
Hi guys,
On Thu, Feb 11, 2010 at 15:25, Dean Michael Berris
<mik...@gm...> wrote:
> I was thinking about this a little and thought it would be cool to
> have a collection of utilities of commonly-performed actions that
> others might find useful in the library. Off the top of my head I find
> that these would be cool functions/mini-libraries to have:
This would be very nice indeed. Also, in my opinion, we need a few
more code examples as I've generally found them to be a good way to
familiarize yourself with a library. Something like a simple HTTP
proxy might even fall in both categories, showing off both the client
and server side of the library.
> * MIME Parser (Marshall Clow has a cool one worthy of more attention
> and discussion, hopefully he merges it into cpp-netlib in time for
> BoostCon 2010 ;) ).
> * Form encoding/decoding (for HTTP clients/servers to handle HTML
> form encoded data)
> * Query string encoding/decoding (for GET queries)
> * Base64 stream/string encoding/decoding (for Binary data)
> * URI pattern-based dispatch (ala Rails, or Django/Tornado)
>
> I find myself wanting to write these myself or at least using them
> when I write programs that use cpp-netlib. Simple things like for HTTP
> server based applications I want to be able to parse a list of
> parameters (remembering what Jeroen was proposing to do with the URI
> parser one time).
The query parser is indeed one of the things currently on the TODO
list for the URI part of the library. Design-wise I was thinking of
something like:
template <class Tag>
bool parse_query(basic_uri<Tag> const & uri, typename query_list<Tag>::type &) {
// TODO Parse using Spirit
return true; // Return whether it was successful.
}
with
template <class Tag>
struct query_list {
typedef typename string<Tag>::type string_type;
typedef typename std::list<std::pair<string_type, string_type> > type;
}
and something along the same lines for query_map for a std::map. This
is off the top of my head, and your thoughts would be very much
appreciated. As I've said before, most of the grunt work has already
been done by Hartmunt in this brilliant article:
http://boost-spirit.com/home/articles/qi-example/parsing-a-list-of-key-value-pairs-using-spirit-qi/
thus with some luck this is actually rather easy.
Secondly, I have the basis of a dispatcher I wrote for libevent
bindings some time ago, which I've attached. There seem to be a few
things which need to be abstracted from though:
- The comparison function
- The type you're comparing to
and quite probably a few more things, as ultimately I'd be very useful
if you could stick in boost::starts_with, something from the regex
library or from the xpressive library to find a match. If anyone finds
this code is of any use for cpp-netlib, I'll stick a boost license on
it.
> Any takers? It would be cool if we had these in the library before May
> where I will be presenting the library and the techniques used in the
> library at a high level. ;)
This is where things get tricky, considering I've just got an
apartment this month and will be moving, I'm quite limited when it
comes to free time unfortunately.
> Hope this helps and I hope to hear from you guys soon too!
>
Hope this is of any use,
Jeroen Habraken
|
|
From: Glyn M. <gly...@gm...> - 2010-02-11 16:35:24
|
Hi Dean, On 11 February 2010 15:25, Dean Michael Berris <mik...@gm...>wrote: > I was thinking about this a little and thought it would be cool to > have a collection of utilities of commonly-performed actions that > others might find useful in the library. Off the top of my head I find > that these would be cool functions/mini-libraries to have: > > * MIME Parser (Marshall Clow has a cool one worthy of more attention > and discussion, hopefully he merges it into cpp-netlib in time for > BoostCon 2010 ;) ). > Where can I get this? Does Marshall intend to merge his work into cpp-netlib or submit it directly to boost? > * Form encoding/decoding (for HTTP clients/servers to handle HTML > form encoded data) > Yes, something in namespace `boost::network::http::forms` ? > * Query string encoding/decoding (for GET queries) This has been proposed before, but I don't think it's ever been implemented. * Base64 stream/string encoding/decoding (for Binary data) > Boost.Serialization already defines base64 encoding/decoding functions, and I would guess that the MIME implementation you mentioned above would too. * URI pattern-based dispatch (ala Rails, or Django/Tornado) > Cool. > > I find myself wanting to write these myself or at least using them > when I write programs that use cpp-netlib. Simple things like for HTTP > server based applications I want to be able to parse a list of > parameters (remembering what Jeroen was proposing to do with the URI > parser one time). > > Any takers? It would be cool if we had these in the library before May > where I will be presenting the library and the techniques used in the > library at a high level. ;) > > Can you add them to the issue tracker, and maybe also to the wiki? This way, anyone who is interested in participating can find something to do. G |
|
From: Dean M. B. <mik...@gm...> - 2010-02-11 16:51:23
|
On Fri, Feb 12, 2010 at 12:27 AM, Jeroen Habraken <vex...@gm...> wrote:
> Hi guys,
>
> On Thu, Feb 11, 2010 at 15:25, Dean Michael Berris
> <mik...@gm...> wrote:
>> I was thinking about this a little and thought it would be cool to
>> have a collection of utilities of commonly-performed actions that
>> others might find useful in the library. Off the top of my head I find
>> that these would be cool functions/mini-libraries to have:
>
> This would be very nice indeed. Also, in my opinion, we need a few
> more code examples as I've generally found them to be a good way to
> familiarize yourself with a library. Something like a simple HTTP
> proxy might even fall in both categories, showing off both the client
> and server side of the library.
>
Code examples are definitely good to have. I'm a little afraid though
that we'd ruffle a few feathers if we implemented something like this.
I've been meaning to do a wicked fast static HTTP server that competes
with lighttpd/nginx in simplicity and performance. My worry would be
that it would be a project that would have its own demons. ;)
>
> The query parser is indeed one of the things currently on the TODO
> list for the URI part of the library. Design-wise I was thinking of
> something like:
>
> template <class Tag>
> bool parse_query(basic_uri<Tag> const & uri, typename query_list<Tag>::type &) {
> // TODO Parse using Spirit
>
> return true; // Return whether it was successful.
> }
>
> with
>
> template <class Tag>
> struct query_list {
> typedef typename string<Tag>::type string_type;
>
> typedef typename std::list<std::pair<string_type, string_type> > type;
> }
>
> and something along the same lines for query_map for a std::map. This
> is off the top of my head, and your thoughts would be very much
> appreciated. As I've said before, most of the grunt work has already
> been done by Hartmunt in this brilliant article:
> http://boost-spirit.com/home/articles/qi-example/parsing-a-list-of-key-value-pairs-using-spirit-qi/
> thus with some luck this is actually rather easy.
>
Sure, but it just assumes the "canonical" form of "key=value&foo=bar".
There's a lot more to query strings than just this form (some use
different delimeters, instead of &, some use |, there's also list and
multi-form notation like "form1[field]=value&form2[field]=value" and
all sorts of funky things). That in itself sounds like a pretty
useful/powerful set of parsers that would definitely make for an
interesting project.
Now I'm seriously considering applying for a Google Summer of Code
thing to get support for the project. :D Maybe after BoostCon and once
more people get to use the library more. ;)
> Secondly, I have the basis of a dispatcher I wrote for libevent
> bindings some time ago, which I've attached. There seem to be a few
> things which need to be abstracted from though:
> - The comparison function
> - The type you're comparing to
> and quite probably a few more things, as ultimately I'd be very useful
> if you could stick in boost::starts_with, something from the regex
> library or from the xpressive library to find a match. If anyone finds
> this code is of any use for cpp-netlib, I'll stick a boost license on
> it.
>
I haven't looked at it yet, but I have a somewhat dormant header-only
library on SourceForge that does pretty much something similar (It's
called the Runtime Dynamic Dispatch Library). I'm looking for
something more flexible though, something that allows me to map a
boost::regex string that contains sub-groups (or named groups) to a
function that has the signature: void(request const &, response &).
Does your implementation do roughly that?
I might come up with a simple implementation and place it in
boost/network/utils -- when I get time to do so that is. ;)
>> Any takers? It would be cool if we had these in the library before May
>> where I will be presenting the library and the techniques used in the
>> library at a high level. ;)
>
> This is where things get tricky, considering I've just got an
> apartment this month and will be moving, I'm quite limited when it
> comes to free time unfortunately.
>
I can understand that completely, having been in that situation
before. May is still a ways away -- you've got time in between now and
then. :D
>> Hope this helps and I hope to hear from you guys soon too!
>>
>
> Hope this is of any use,
I'll take a look and I encourage others in the list to do the same. :)
--
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Jeroen H. <vex...@gm...> - 2010-02-11 22:00:50
|
Hi,
On Thu, Feb 11, 2010 at 17:50, Dean Michael Berris
<mik...@gm...> wrote:
> On Fri, Feb 12, 2010 at 12:27 AM, Jeroen Habraken <vex...@gm...> wrote:
>> Hi guys,
>>
>> On Thu, Feb 11, 2010 at 15:25, Dean Michael Berris
>> <mik...@gm...> wrote:
>>> I was thinking about this a little and thought it would be cool to
>>> have a collection of utilities of commonly-performed actions that
>>> others might find useful in the library. Off the top of my head I find
>>> that these would be cool functions/mini-libraries to have:
>>
>> This would be very nice indeed. Also, in my opinion, we need a few
>> more code examples as I've generally found them to be a good way to
>> familiarize yourself with a library. Something like a simple HTTP
>> proxy might even fall in both categories, showing off both the client
>> and server side of the library.
>>
>
> Code examples are definitely good to have. I'm a little afraid though
> that we'd ruffle a few feathers if we implemented something like this.
> I've been meaning to do a wicked fast static HTTP server that competes
> with lighttpd/nginx in simplicity and performance. My worry would be
> that it would be a project that would have its own demons. ;)
>
>>
>> The query parser is indeed one of the things currently on the TODO
>> list for the URI part of the library. Design-wise I was thinking of
>> something like:
>>
>> template <class Tag>
>> bool parse_query(basic_uri<Tag> const & uri, typename query_list<Tag>::type &) {
>> // TODO Parse using Spirit
>>
>> return true; // Return whether it was successful.
>> }
>>
>> with
>>
>> template <class Tag>
>> struct query_list {
>> typedef typename string<Tag>::type string_type;
>>
>> typedef typename std::list<std::pair<string_type, string_type> > type;
>> }
>>
>> and something along the same lines for query_map for a std::map. This
>> is off the top of my head, and your thoughts would be very much
>> appreciated. As I've said before, most of the grunt work has already
>> been done by Hartmunt in this brilliant article:
>> http://boost-spirit.com/home/articles/qi-example/parsing-a-list-of-key-value-pairs-using-spirit-qi/
>> thus with some luck this is actually rather easy.
>>
>
> Sure, but it just assumes the "canonical" form of "key=value&foo=bar".
> There's a lot more to query strings than just this form (some use
> different delimeters, instead of &, some use |, there's also list and
> multi-form notation like "form1[field]=value&form2[field]=value" and
> all sorts of funky things). That in itself sounds like a pretty
> useful/powerful set of parsers that would definitely make for an
> interesting project.
I know, and worse, as far as I know there is no official specification
on how this is done. At least, it's not in any RFC that I know, and I
couldn't find anything from W3C either. If I'm wrong, and might well
be, a link to the specs would be very much appreciated.
> Now I'm seriously considering applying for a Google Summer of Code
> thing to get support for the project. :D Maybe after BoostCon and once
> more people get to use the library more. ;)
+1
>> Secondly, I have the basis of a dispatcher I wrote for libevent
>> bindings some time ago, which I've attached. There seem to be a few
>> things which need to be abstracted from though:
>> - The comparison function
>> - The type you're comparing to
>> and quite probably a few more things, as ultimately I'd be very useful
>> if you could stick in boost::starts_with, something from the regex
>> library or from the xpressive library to find a match. If anyone finds
>> this code is of any use for cpp-netlib, I'll stick a boost license on
>> it.
>>
>
> I haven't looked at it yet, but I have a somewhat dormant header-only
> library on SourceForge that does pretty much something similar (It's
> called the Runtime Dynamic Dispatch Library). I'm looking for
> something more flexible though, something that allows me to map a
> boost::regex string that contains sub-groups (or named groups) to a
> function that has the signature: void(request const &, response &).
>
> Does your implementation do roughly that?
>
> I might come up with a simple implementation and place it in
> boost/network/utils -- when I get time to do so that is. ;)
No, my code is trivial in every way (it was written before I learned
most techniques on writing generic code, and it was written
specifically for one application), but it might offer a starting
point.
>>> Any takers? It would be cool if we had these in the library before May
>>> where I will be presenting the library and the techniques used in the
>>> library at a high level. ;)
>>
>> This is where things get tricky, considering I've just got an
>> apartment this month and will be moving, I'm quite limited when it
>> comes to free time unfortunately.
>>
>
> I can understand that completely, having been in that situation
> before. May is still a ways away -- you've got time in between now and
> then. :D
Yeah, it's just that I can't plan anything. I've been thinking about
what I'd like to add to 0.7 etcetera, but this is kind of hard not
knowing how much time I can spend on it.
>>> Hope this helps and I hope to hear from you guys soon too!
>>>
>>
>> Hope this is of any use,
>
> I'll take a look and I encourage others in the list to do the same. :)
>
> --
> Dean Michael Berris
> cplusplus-soup.com | twitter.com/deanberris
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>
Jeroen
|
|
From: Glyn M. <gly...@gm...> - 2010-02-11 16:55:57
|
Hi, On 11 February 2010 17:50, Dean Michael Berris <mik...@gm...>wrote: > > Now I'm seriously considering applying for a Google Summer of Code > thing to get support for the project. :D Maybe after BoostCon and once > more people get to use the library more. ;) > GSoC would be a superb idea, but I think the deadlien for submissions is going to be before BoostCon, so we should use this opportunity to get some proposals together if we want to go for it. G |
|
From: Dean M. B. <mik...@gm...> - 2010-02-11 17:00:20
|
On Fri, Feb 12, 2010 at 12:35 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > On 11 February 2010 15:25, Dean Michael Berris <mik...@gm...> > wrote: >> >> * MIME Parser (Marshall Clow has a cool one worthy of more attention >> and discussion, hopefully he merges it into cpp-netlib in time for >> BoostCon 2010 ;) ). > > Where can I get this? Does Marshall intend to merge his work into cpp-netlib > or submit it directly to boost? > Marshall and I have been conversing off-list and I have copies of his work in my inbox. I haven't gotten the time to really integrate it into cpp-netlib but he does have a github account now. I'm not sure if he's on the list yet (I can check) but he has expressed interest in merging his implementation into cpp-netlib for eventual submission to Boost. We'll be working together to merge his library into cpp-netlib and maybe do a joint presentation on BoostCon 2010. I see that he's done cool stuff with his MIME encoder/decoder and I do look forward to seeing his implementation in cpp-netlib sooner than later. Marshall, if you're on the list this is your cue. :D >> >> * Form encoding/decoding (for HTTP clients/servers to handle HTML >> form encoded data) > > Yes, something in namespace `boost::network::http::forms` ? > That's still up for grabs. If you'd like to take a crack at it please be my guest. :D I'm thinking initially it would be cool to have it in `boost::network::http::utils` and glob together the different utility functions/types there. I'm also thinking of a higher level utils namespace like `boost::network::utils::html::forms`. Maybe one day we'll also have an HTML/XML DSEL that compiles to wicked fast rendering code for those serious with using cpp-netlib's embeddable HTTP server as an application server. Now *that* I think personally would be cool, but I'm afraid is a little out of the scope of cpp-netlib. :D >> >> * Query string encoding/decoding (for GET queries) > > This has been proposed before, but I don't think it's ever been > implemented. > Yeah, I think Jeroen has a more concrete idea on how to do it. :) >> * Base64 stream/string encoding/decoding (for Binary data) > > Boost.Serialization already defines base64 encoding/decoding functions, and > I would guess that the MIME implementation you mentioned above would too. Yeah, I tought about that a little more and I think just base64 encoding would be too low-level. The MIME implementation and Boost.Serialization would be good places to see it. We can safely remove that from the list. :) >> >> * URI pattern-based dispatch (ala Rails, or Django/Tornado) > > Cool. > Cool indeed. :) > > Can you add them to the issue tracker, and maybe also to the wiki? This > way, anyone who is interested in participating can find something to do. Wiki it is, I shall do a "brain dump" on the cpp-netlib.github.com wiki then. :D Thanks for the response Glyn! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-02-11 22:26:32
|
On Thu, Feb 11, 2010 at 17:59, Dean Michael Berris <mik...@gm...> wrote: > On Fri, Feb 12, 2010 at 12:35 AM, Glyn Matthews <gly...@gm...> wrote: >> Hi Dean, >> >> On 11 February 2010 15:25, Dean Michael Berris <mik...@gm...> >> wrote: >>> >>> * MIME Parser (Marshall Clow has a cool one worthy of more attention >>> and discussion, hopefully he merges it into cpp-netlib in time for >>> BoostCon 2010 ;) ). >> >> Where can I get this? Does Marshall intend to merge his work into cpp-netlib >> or submit it directly to boost? >> > > Marshall and I have been conversing off-list and I have copies of his > work in my inbox. I haven't gotten the time to really integrate it > into cpp-netlib but he does have a github account now. I'm not sure if > he's on the list yet (I can check) but he has expressed interest in > merging his implementation into cpp-netlib for eventual submission to > Boost. > > We'll be working together to merge his library into cpp-netlib and > maybe do a joint presentation on BoostCon 2010. I see that he's done > cool stuff with his MIME encoder/decoder and I do look forward to > seeing his implementation in cpp-netlib sooner than later. > > Marshall, if you're on the list this is your cue. :D Great! >>> >>> * Form encoding/decoding (for HTTP clients/servers to handle HTML >>> form encoded data) >> >> Yes, something in namespace `boost::network::http::forms` ? >> > > That's still up for grabs. If you'd like to take a crack at it please > be my guest. :D > > I'm thinking initially it would be cool to have it in > `boost::network::http::utils` and glob together the different utility > functions/types there. I'm also thinking of a higher level utils > namespace like `boost::network::utils::html::forms`. > > Maybe one day we'll also have an HTML/XML DSEL that compiles to wicked > fast rendering code for those serious with using cpp-netlib's > embeddable HTTP server as an application server. Now *that* I think > personally would be cool, but I'm afraid is a little out of the scope > of cpp-netlib. :D > >>> >>> * Query string encoding/decoding (for GET queries) >> >> This has been proposed before, but I don't think it's ever been >> implemented. >> > > Yeah, I think Jeroen has a more concrete idea on how to do it. :) I've decided to try to take this on, and moved it up on my TODO list, as shown by the number of requests it's just something we need! As this is mostly Boost.Spirit work, it'll be something done incrementally (using Spirit seems to come down to writing a bit of code, giving compiling it a shot, figuring out what character you've misplaced this time, rinse and repeat :)). Initially the simple query strings as found in GET requests seem to be a nice goal, which if set up generically enough should later allow them to be extended to POST requests. The design and location of this is going to need some though, and any input is welcome. Do we want to integrate it into the URI parser and classes, in a separate namespace or as a 'utility' if such a category is going to exist? >>> * Base64 stream/string encoding/decoding (for Binary data) >> >> Boost.Serialization already defines base64 encoding/decoding functions, and >> I would guess that the MIME implementation you mentioned above would too. > > Yeah, I tought about that a little more and I think just base64 > encoding would be too low-level. The MIME implementation and > Boost.Serialization would be good places to see it. We can safely > remove that from the list. :) Yeah, I agree. >>> >>> * URI pattern-based dispatch (ala Rails, or Django/Tornado) >> >> Cool. >> > > Cool indeed. :) > >> >> Can you add them to the issue tracker, and maybe also to the wiki? This >> way, anyone who is interested in participating can find something to do. > > Wiki it is, I shall do a "brain dump" on the cpp-netlib.github.com wiki then. :D > > Thanks for the response Glyn! > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-02-11 17:02:05
|
On Fri, Feb 12, 2010 at 12:55 AM, Glyn Matthews <gly...@gm...> wrote: > > On 11 February 2010 17:50, Dean Michael Berris <mik...@gm...> > wrote: >> >> Now I'm seriously considering applying for a Google Summer of Code >> thing to get support for the project. :D Maybe after BoostCon and once >> more people get to use the library more. ;) > > GSoC would be a superb idea, but I think the deadlien for submissions is > going to be before BoostCon, so we should use this opportunity to get some > proposals together if we want to go for it. Ooooh, that was just a wild thought -- I didn't think it was open! Yes, maybe we should Wave those proposals? :D -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-02-11 21:46:45
|
On 11 February 2010 18:01, Dean Michael Berris <mik...@gm...>wrote: > On Fri, Feb 12, 2010 at 12:55 AM, Glyn Matthews <gly...@gm...> > wrote: > > > > On 11 February 2010 17:50, Dean Michael Berris <mik...@gm...> > > wrote: > >> > >> Now I'm seriously considering applying for a Google Summer of Code > >> thing to get support for the project. :D Maybe after BoostCon and once > >> more people get to use the library more. ;) > > > > GSoC would be a superb idea, but I think the deadlien for submissions is > > going to be before BoostCon, so we should use this opportunity to get > some > > proposals together if we want to go for it. > > Ooooh, that was just a wild thought -- I didn't think it was open! > > Yes, maybe we should Wave those proposals? :D > Yep, I started one. G |
|
From: Darren G. <dar...@gm...> - 2010-02-11 17:03:23
|
Hi Dean,
On 11 February 2010 14:25, Dean Michael Berris <mik...@gm...>wrote:
> I was thinking about this a little and thought it would be cool to
> have a collection of utilities of commonly-performed actions that
> others might find useful in the library. Off the top of my head I find
> that these would be cool functions/mini-libraries to have:
* MIME Parser (Marshall Clow has a cool one worthy of more attention
> and discussion, hopefully he merges it into cpp-netlib in time for
> BoostCon 2010 ;) ).
>
I've taken a look at this. It looks pretty cool, like it could fit the bill.
Two extra features that I would find very useful are:
* Either:
- Ability to restart the parser - ie. support chunked data.
or:
- Ability to pass in a Boost.Asio-compatible *ReadStream instead of an
istream.
* Ability to store file uploads directly to the filesystem (ie. so you can
support uploading huge files).
Marshall, are you planning to integrate your MIME parser with cpp-netlib?
* Form encoding/decoding (for HTTP clients/servers to handle HTML
> form encoded data)
> * Query string encoding/decoding (for GET queries)
> * Base64 stream/string encoding/decoding (for Binary data)
>
There is overlap with the CGI library under development. Is there anything
we can do to find some common ground here?
> * URI pattern-based dispatch (ala Rails, or Django/Tornado)
>
Very useful feature, but must be kept distinctly separate from the core
IMHO. I have some code which does dynamic dispatching of handlers based on
regular expressions matching with the path-info of a request. This also
dispatches to a specific handler depending on the request-method of the
request. For example:
// One of many potential request handlers:
struct some_handler : request_handler<some_handler, Context>
{
int get(Context& self) { /* ... */ }
int post(Context& self, boost::regex_match& url_matches) { /* ... */ }
int put(Context& self) { /* ... */ }
};
The above pattern uses virtual functions to allow it to work. When a handler
for the specified request method isn't found, this is captured in the base
class. If the handler overrides the base class method, the handler's method
is called. The handler is able to have an optional regex_match argument,
which allows the regular expression of the match to use sub-matches.
For example, the url pattern "(/*)" would match any request and attempt to
call the relevant handler. If the handler took a regex_match, this would be
called with the full path_info of the request.
The code doesn't currently fall back to a handler that works with any
request method, but could easily enough. Also, it may benefit from some
metaprogramming to make the dispatching static... My feelings at the time
were that one or two virtual function calls per request are fine - feel free
to disagree!
Thoughts?
> I find myself wanting to write these myself or at least using them
> when I write programs that use cpp-netlib. Simple things like for HTTP
> server based applications I want to be able to parse a list of
> parameters (remembering what Jeroen was proposing to do with the URI
> parser one time).
>
> Any takers? It would be cool if we had these in the library before May
> where I will be presenting the library and the techniques used in the
> library at a high level. ;)
>
Not sure how much time I'll have to spare as I'm quite busy with work and
pushing to getting a release of the CGI library out ASAP. I use
Boost.Tokenizer for splitting query strings and cookies and a custom
url_decode function for parsing. The data is stored in std::map<>s, with a
case-insensitive string as the key_type.
That said, these aren't using Spirit yet. Maybe compilers are fast enough to
deal with sprinklings of Spirit coolness everywhere now?
Cheers,
Darren
|
|
From: Dean M. B. <mik...@gm...> - 2010-02-11 17:27:50
|
Hey Darren!
It's great to see you here. :)
On Fri, Feb 12, 2010 at 1:02 AM, Darren Garvey <dar...@gm...> wrote:
>
> On 11 February 2010 14:25, Dean Michael Berris <mik...@gm...>
> wrote:
>>
>> I was thinking about this a little and thought it would be cool to
>> have a collection of utilities of commonly-performed actions that
>> others might find useful in the library. Off the top of my head I find
>> that these would be cool functions/mini-libraries to have:
>>
>> * MIME Parser (Marshall Clow has a cool one worthy of more attention
>> and discussion, hopefully he merges it into cpp-netlib in time for
>> BoostCon 2010 ;) ).
>
> I've taken a look at this. It looks pretty cool, like it could fit the bill.
> Two extra features that I would find very useful are:
>
> * Either:
> - Ability to restart the parser - ie. support chunked data.
> or:
> - Ability to pass in a Boost.Asio-compatible *ReadStream instead of an
> istream.
> * Ability to store file uploads directly to the filesystem (ie. so you can
> support uploading huge files).
>
I think Marshall has taken the input from the boost-devel mailing list
regarding this and *might* be working on something similar. I'm not
sure though what his timetable on that would be. :)
> Marshall, are you planning to integrate your MIME parser with cpp-netlib?
>
/me silently wishes Marshall does! :D
>> * Form encoding/decoding (for HTTP clients/servers to handle HTML
>> form encoded data)
>> * Query string encoding/decoding (for GET queries)
>> * Base64 stream/string encoding/decoding (for Binary data)
>
> There is overlap with the CGI library under development. Is there anything
> we can do to find some common ground here?
>
Definitely!
Have you looked at the HTTP Server template yet? It's very bare and if
we can plug in the CGI handlers through the HTTP Server template then
I think my search for one half of a C++ Application Servlet Container
would be complete. The other half would only be actual session
handling and persistence subsystem managers. :D
>>
>> * URI pattern-based dispatch (ala Rails, or Django/Tornado)
>
> Very useful feature, but must be kept distinctly separate from the core
> IMHO.
100% agree. I'm thinking this alone would be cool in its own right and
might be a full-blown library waiting to happen. I can definitely see
this being useful in other contexts like command consoles, scripting
interfaces, etc. -- which is also why I'm thinking a utilities
collection would be a good place to host something like this. ;)
> I have some code which does dynamic dispatching of handlers based on
> regular expressions matching with the path-info of a request. This also
> dispatches to a specific handler depending on the request-method of the
> request. For example:
>
> // One of many potential request handlers:
> struct some_handler : request_handler<some_handler, Context>
> {
> int get(Context& self) { /* ... */ }
> int post(Context& self, boost::regex_match& url_matches) { /* ... */ }
> int put(Context& self) { /* ... */ }
> };
>
> The above pattern uses virtual functions to allow it to work. When a handler
> for the specified request method isn't found, this is captured in the base
> class. If the handler overrides the base class method, the handler's method
> is called. The handler is able to have an optional regex_match argument,
> which allows the regular expression of the match to use sub-matches.
>
> For example, the url pattern "(/*)" would match any request and attempt to
> call the relevant handler. If the handler took a regex_match, this would be
> called with the full path_info of the request.
>
This sounds like exactly what I'm looking for. My only gripe is that
it uses virtual functions. ;)
> The code doesn't currently fall back to a handler that works with any
> request method, but could easily enough. Also, it may benefit from some
> metaprogramming to make the dispatching static... My feelings at the time
> were that one or two virtual function calls per request are fine - feel free
> to disagree!
>
Actually, I think you can get away with a chain pattern, using
Boost.Fusion for compile-time wired static dispatch. If I understand
it correctly, you might be able to get away with a combination of
Boost.Xpressive for the statically defined regex's and handlers that
adhere to a certain Concept.
The recipe would involve (from the top of my head) a Fusion sequence
of pairs of Xpressive patterns and opaque handlers. You run it through
Fusion's `any` function and find the first match and invoke the
associated handler. Given a little more prodding I might implement it
myself just as an exercise on Fusion, Xpressive, and some
metaprogramming kung fu. :)
>
>>
>> I find myself wanting to write these myself or at least using them
>> when I write programs that use cpp-netlib. Simple things like for HTTP
>> server based applications I want to be able to parse a list of
>> parameters (remembering what Jeroen was proposing to do with the URI
>> parser one time).
>>
>> Any takers? It would be cool if we had these in the library before May
>> where I will be presenting the library and the techniques used in the
>> library at a high level. ;)
>
> Not sure how much time I'll have to spare as I'm quite busy with work and
> pushing to getting a release of the CGI library out ASAP. I use
> Boost.Tokenizer for splitting query strings and cookies and a custom
> url_decode function for parsing. The data is stored in std::map<>s, with a
> case-insensitive string as the key_type.
>
> That said, these aren't using Spirit yet. Maybe compilers are fast enough to
> deal with sprinklings of Spirit coolness everywhere now?
>
Boost.Spirit FTW -- the cost of compile times definitely justify the
performance gains at runtime. :)
> Cheers,
> Darren
>
Thanks for sharing your thoughts Darren! I hope some of my thoughts help too. :D
I'm also looking forward to the CGI library. :)
--
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Jeroen H. <vex...@gm...> - 2010-02-11 22:41:26
|
Hi again,
On Thu, Feb 11, 2010 at 18:27, Dean Michael Berris
<mik...@gm...> wrote:
> Hey Darren!
>
> It's great to see you here. :)
>
> On Fri, Feb 12, 2010 at 1:02 AM, Darren Garvey <dar...@gm...> wrote:
>>
>> On 11 February 2010 14:25, Dean Michael Berris <mik...@gm...>
>> wrote:
>>>
>>> I was thinking about this a little and thought it would be cool to
>>> have a collection of utilities of commonly-performed actions that
>>> others might find useful in the library. Off the top of my head I find
>>> that these would be cool functions/mini-libraries to have:
>>>
>>> * MIME Parser (Marshall Clow has a cool one worthy of more attention
>>> and discussion, hopefully he merges it into cpp-netlib in time for
>>> BoostCon 2010 ;) ).
>>
>> I've taken a look at this. It looks pretty cool, like it could fit the bill.
>> Two extra features that I would find very useful are:
>>
>> * Either:
>> - Ability to restart the parser - ie. support chunked data.
>> or:
>> - Ability to pass in a Boost.Asio-compatible *ReadStream instead of an
>> istream.
>> * Ability to store file uploads directly to the filesystem (ie. so you can
>> support uploading huge files).
>>
>
> I think Marshall has taken the input from the boost-devel mailing list
> regarding this and *might* be working on something similar. I'm not
> sure though what his timetable on that would be. :)
>
>> Marshall, are you planning to integrate your MIME parser with cpp-netlib?
>>
>
> /me silently wishes Marshall does! :D
>
>>> * Form encoding/decoding (for HTTP clients/servers to handle HTML
>>> form encoded data)
>>> * Query string encoding/decoding (for GET queries)
>>> * Base64 stream/string encoding/decoding (for Binary data)
>>
>> There is overlap with the CGI library under development. Is there anything
>> we can do to find some common ground here?
>>
>
> Definitely!
>
> Have you looked at the HTTP Server template yet? It's very bare and if
> we can plug in the CGI handlers through the HTTP Server template then
> I think my search for one half of a C++ Application Servlet Container
> would be complete. The other half would only be actual session
> handling and persistence subsystem managers. :D
>
>>>
>>> * URI pattern-based dispatch (ala Rails, or Django/Tornado)
>>
>> Very useful feature, but must be kept distinctly separate from the core
>> IMHO.
>
> 100% agree. I'm thinking this alone would be cool in its own right and
> might be a full-blown library waiting to happen. I can definitely see
> this being useful in other contexts like command consoles, scripting
> interfaces, etc. -- which is also why I'm thinking a utilities
> collection would be a good place to host something like this. ;)
I agree this must be kept distinctly separate from the core, and I
think we need to decide how far we want to take this. In its simplest
form it would be a very handy utility, which shows the basics of what
can be done, though in it's most extensive form it would indeed be a
full-blown library. The former seems to be nice to have around May,
mostly to show how the library can be used in practice.
>> I have some code which does dynamic dispatching of handlers based on
>> regular expressions matching with the path-info of a request. This also
>> dispatches to a specific handler depending on the request-method of the
>> request. For example:
>>
>> // One of many potential request handlers:
>> struct some_handler : request_handler<some_handler, Context>
>> {
>> int get(Context& self) { /* ... */ }
>> int post(Context& self, boost::regex_match& url_matches) { /* ... */ }
>> int put(Context& self) { /* ... */ }
>> };
>>
>> The above pattern uses virtual functions to allow it to work. When a handler
>> for the specified request method isn't found, this is captured in the base
>> class. If the handler overrides the base class method, the handler's method
>> is called. The handler is able to have an optional regex_match argument,
>> which allows the regular expression of the match to use sub-matches.
>>
>> For example, the url pattern "(/*)" would match any request and attempt to
>> call the relevant handler. If the handler took a regex_match, this would be
>> called with the full path_info of the request.
>>
>
> This sounds like exactly what I'm looking for. My only gripe is that
> it uses virtual functions. ;)
>
>> The code doesn't currently fall back to a handler that works with any
>> request method, but could easily enough. Also, it may benefit from some
>> metaprogramming to make the dispatching static... My feelings at the time
>> were that one or two virtual function calls per request are fine - feel free
>> to disagree!
>>
>
> Actually, I think you can get away with a chain pattern, using
> Boost.Fusion for compile-time wired static dispatch. If I understand
> it correctly, you might be able to get away with a combination of
> Boost.Xpressive for the statically defined regex's and handlers that
> adhere to a certain Concept.
>
> The recipe would involve (from the top of my head) a Fusion sequence
> of pairs of Xpressive patterns and opaque handlers. You run it through
> Fusion's `any` function and find the first match and invoke the
> associated handler. Given a little more prodding I might implement it
> myself just as an exercise on Fusion, Xpressive, and some
> metaprogramming kung fu. :)
This might be pushing people in the direction of Xpressive when
there's no need for it, simple prefix matching is often enough. Could
this be done either simpler, or more generically?
>>
>>>
>>> I find myself wanting to write these myself or at least using them
>>> when I write programs that use cpp-netlib. Simple things like for HTTP
>>> server based applications I want to be able to parse a list of
>>> parameters (remembering what Jeroen was proposing to do with the URI
>>> parser one time).
>>>
>>> Any takers? It would be cool if we had these in the library before May
>>> where I will be presenting the library and the techniques used in the
>>> library at a high level. ;)
>>
>> Not sure how much time I'll have to spare as I'm quite busy with work and
>> pushing to getting a release of the CGI library out ASAP. I use
>> Boost.Tokenizer for splitting query strings and cookies and a custom
>> url_decode function for parsing. The data is stored in std::map<>s, with a
>> case-insensitive string as the key_type.
>>
>> That said, these aren't using Spirit yet. Maybe compilers are fast enough to
>> deal with sprinklings of Spirit coolness everywhere now?
>>
>
> Boost.Spirit FTW -- the cost of compile times definitely justify the
> performance gains at runtime. :)
Very much so :)
>> Cheers,
>> Darren
>>
>
> Thanks for sharing your thoughts Darren! I hope some of my thoughts help too. :D
>
> I'm also looking forward to the CGI library. :)
>
> --
> Dean Michael Berris
> cplusplus-soup.com | twitter.com/deanberris
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>
Jeroen
|
|
From: Marshall C. <mcl...@gm...> - 2010-02-27 03:10:51
|
On Feb 11, 2010, at 9:02 AM, Darren Garvey wrote: > Hi Dean, > > On 11 February 2010 14:25, Dean Michael Berris <mik...@gm...> wrote: > I was thinking about this a little and thought it would be cool to > have a collection of utilities of commonly-performed actions that > others might find useful in the library. Off the top of my head I find > that these would be cool functions/mini-libraries to have: > * MIME Parser (Marshall Clow has a cool one worthy of more attention > and discussion, hopefully he merges it into cpp-netlib in time for > BoostCon 2010 ;) ). > > I've taken a look at this. It looks pretty cool, like it could fit the bill. Two extra features that I would find very useful are: > > * Either: > - Ability to restart the parser - ie. support chunked data. > or: > - Ability to pass in a Boost.Asio-compatible *ReadStream instead of an istream. > * Ability to store file uploads directly to the filesystem (ie. so you can support uploading huge files). > > Marshall, are you planning to integrate your MIME parser with cpp-netlib? > [ Sorry for the long delay - work jumped up and bit me hard ] Yes and no. ;-) I think that the MIME routines (parser, storage, manipulation, and output) should be a separate library from cpp-netlib. However, I have no problem with cpp-netlib using it, and I will be checking it into the cpp-netlib github repo so that development of the two can continue together. -- Marshall P.S. The reasoning behind this that other libraries in boost might want to consume/create/manipulate MIME messages. P.P.S. If you *completely* hate this, let me know and we can hash it out. |
|
From: Darren G. <dar...@gm...> - 2010-02-27 15:34:23
|
Hi Marshall, On 27 February 2010 03:10, Marshall Clow <mcl...@gm...> wrote: > On Feb 11, 2010, at 9:02 AM, Darren Garvey wrote: > > I've taken a look at this. It looks pretty cool, like it could fit the > bill. Two extra features that I would find very useful are: > > * Either: > - Ability to restart the parser - ie. support chunked data. > or: > - Ability to pass in a Boost.Asio-compatible *ReadStream instead of an > istream. > * Ability to store file uploads directly to the filesystem (ie. so you can > support uploading huge files). > > Marshall, are you planning to integrate your MIME parser with cpp-netlib? > > > [ Sorry for the long delay - work jumped up and bit me hard ] > > Yes and no. ;-) > > I think that the MIME routines (parser, storage, manipulation, and output) > should be a separate library from cpp-netlib. > Yes, for sure. MIME parsing is generally useful enough to justify a library in itself... Equally, I think a URL library would be useful in and of itself too. > However, I have no problem with cpp-netlib using it, and I will be > checking it into the cpp-netlib github repo so that development of the two > can continue together. > This is how I saw it being done. Please let us know when you check this in! > -- Marshall > > P.S. The reasoning behind this that other libraries in boost might want to > consume/create/manipulate MIME messages. > eg. A CGI library. ;o) > P.P.S. If you *completely* hate this, let me know and we can hash it out. > Sounds good to me. Cheers, Darren |
|
From: Dean M. B. <mik...@gm...> - 2010-03-01 14:15:24
|
On Sat, Feb 27, 2010 at 11:10 AM, Marshall Clow <mcl...@gm...> wrote: > On Feb 11, 2010, at 9:02 AM, Darren Garvey wrote: >> >> >> Marshall, are you planning to integrate your MIME parser with cpp-netlib? > > > [ Sorry for the long delay - work jumped up and bit me hard ] I know that just all too well. :) > Yes and no. ;-) Cool. :D > I think that the MIME routines (parser, storage, manipulation, and output) > should be a separate library from cpp-netlib. > However, I have no problem with cpp-netlib using it, and I will be checking > it into the cpp-netlib github repo so that development of the two can > continue together. Cool. :D > -- Marshall > P.S. The reasoning behind this that other libraries in boost might want to > consume/create/manipulate MIME messages. I agree 100%. > P.P.S. If you *completely* hate this, let me know and we can hash it out. No objection from me. :) -- Dean Michael Berris deanberris.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X