Hi Jeroen, On Sat, Dec 5, 2009 at 5:40 AM, Jeroen Habraken <[email protected]> wrote: > On Fri, Dec 4, 2009 at 21:47, Dean Michael Berris >> [snip] > > Hi, my two cents on a couple of the above questions, > > 1. Whether we want to support request pipelining on the server side. > It is certainly a nice feature to have, but on most browsers it is > disabled by default, mostly due to the head of line blocking it > creates, and existing buggy proxy implementations, thus I'd leave it > out for now, it shouldn't be a priority of any kind in my opinion. >
Alright. :) >> 2. Whether we want to make it more like a Java framework. > I've personally never liked Java that much, but in what way ? > Java Container Framework I mis-wrote. I mean something like the Apache Tomcat container environment where there's a specification of the interfaces that developers just build upon. >> 3. Whether we want to unify the request object that the HTTP server >> currently uses and the request object that the HTTP client users. > I've previously used libevent, a library in which this object is > unified, and it has been a pain in writing a wrapper. I would > certainly advise against unifying them from this experience, although > they obviously share quite a bit of common ground. It might be nice to > have a look at http://monkey.org/~provos/libevent/doxygen-2.0.1/http_8h.html, > as they support most of the HTTP 1.1 specification, on how they've > designed their API. > Right. I've been wrestling with the idea of using a different namespace or even a different type (which I settled on for the meantime) for the server request. I guess I'll keep it simple in the meantime. FWIW the http::response type is for the client use, while the http::reply type is for the server use. I don't mind keeping it that way but the names can get you misled easily. Anybody else has an idea on how to address this issue? >> 4. What you would like to see in the HTTP Server implementation aside from >> full standard HTTP 1.1 support. > Support for a dispatcher is what comes to mind first of all, thus a > system using which you can registers handlers for URI requests from > the server. I've currently written something trivial of this kind > using boost::startswith, but this can be a lot more general, and > extended to support boost::regex and boost::xpressive for example. As > a sidenote, note that requestst can be an absolute URI in HTTP 1.0, > which you need to strip down to an absolute path for such a dispatcher > for example. Support for virtual hosts could for example also be > achieved using this. > Sounds like a good idea. A generic or "reference" dispatcher implementation can be something worth working on. I can envision something like this: http::dispatcher c = list_of( make_pair(regex("^/$"), foo()), // foo is a function object type make_pair(regex("^/bar$"), bar()) // bar is a function object type ); // signatures of foo/bar should support void(request, reply); http::server s(c); s.run(); Of course a cleaner API would be better too. ;) > If I come up with more tomorrow, I'll write up a more extensive reply. > Thanks Jeroen, I'm looking forward to your more extensive reply. BTW, have you tried the server implementation yet? I'll try to come up with a better example than "Hello, World!". :) -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
