Re: [cpp-netlib-devel] Help! Grammar for parsing HTTP URLs

[Dean M. B. <mik...@gm...>]

On Sun, Aug 16, 2009 at 10:22 PM, John P. Feltz<jf...@ov...> wrote:
>
> Dean Michael Berris wrote:
>>
>> Cool! Are you using Boost.Spirit 2x? I haven't been looking at these
>> changes closely.
>>
>
> To be truthful I haven't even bothered to determine that. Spirit 2 was
> and still is for me- ambiguous. I simply chose to base that work off the
> boost_139 spirit docs.
>

Ah, okay. Well it should be alright -- it should be Spirit 2 if it's
Boost 1.39. Although I may be wrong.

>> Of course that's a lot of work down the road, but the current
>> (not-so-well-tested) implementation seems to be able to identify
>> between HTTP and HTTPS ports. From there we should be able to write
>> the stuff that allows the HTTP client to create its own connections
>> based on the protocol(http_message.url()) -- if it's "https" then use
>> the ssl::socket and if it's just "http" use the normal tcp::socket.
>> That needs to be ironed out and refactored into a separate logic for
>> connection handling.
>>
>>
> That seems rational. Actually, after a stint of researching some Java
> and Python based networking libraries, I myself have come the conclusion
> that presenting the user with a configurable connection object for a
> particular protocol is preferred, in addition to a client facade for
> common use-cases.

Right. But my only reservation against this is that that's too much
work for the user.

I want to be able to do something like:

http::request normal("http://www.boost.org");
http::request https("https://www.boost.org");
http::client c;
http::response normal_response = c.get(normal);
http::response http_response = c.get(https);

And it should "just work".

> As a side note, I have also come to the conclusion
> that a mailing list is not my preferred forum for this sort of
> discussion, which is better suited by collaborative specifications and
> conferencing. I'm curious as to what the opinions of the other
> developers are on this.
>

While we're on the subject, I don't like making documents for one,
which explains why I can't get myself to put a roadmap document. ;)
Nor do I like writing specification documents -- I feel that's a waste
of my time.

I'd rather show client code that works and hide the plumbing so that I
(and everyone else working on the project) can just "make it work"
without having to burden the client (or the person reading the
documentation) with too many details.

Although for our sake, I think we need a coherent place to put the
information in -- so that we don't just put the details in mailing
list archives. However, I am not the best person to write that
document; although I feel like I should be the one doing it. :|

At any rate, I agree that mailing lists aren't the best means for
ironing out specifications or design documents -- however I feel
discussions can be best held here about the approach. It's (for me)
the medium of least resistance as far as collaboration goes. I don't
mind a Wiki page that says what we mean to say in one place, but
before we put anything up to a Wiki I think there should be some sort
of discussion that we can keep going on a mailing list -- then later
we can lift the results of the discussion into a Wiki.

This has worked for me in my time as a developer, because it kills two
birds with one stone -- the rationale is ironed out in the mailing
list while the outcome is put in the Wiki.

I hope this makes sense. :-)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com