cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] URI and shipping 0.4

[Kim G. <kim...@gm...>]

Hi Glyn,

On Thu, Oct 1, 2009 at 10:03, Glyn Matthews <gly...@gm...> wrote:
>
> 2009/10/1 Kim Gräsman <kim...@gm...>
>>
>> On Wed, Sep 30, 2009 at 21:26, Glyn Matthews <gly...@gm...>
>> wrote:
>>
>> I've abandoned my part in that, so we might as well kill off the uri
>> branch (I hope that was where I was mucking about). I just yesterday
>> got cpp-netlib building on my new laptop after a 9-month hiatus.
>>
>
> Thanks for the update  Are you still interested in contributing to the URI?

Yeah, but not actively, I don't have all that much free time at the
moment. I'll chip in with test cases and surly remarks if I stumble
over something :)

- Kim

Re: [cpp-netlib-devel] URI and shipping 0.4

[Glyn M. <gly...@gm...>]

Hi Kim,

2009/10/1 Kim Gräsman <kim...@gm...>

> Hi Glyn,
>
> On Wed, Sep 30, 2009 at 21:26, Glyn Matthews <gly...@gm...>
> wrote:
>
> I've abandoned my part in that, so we might as well kill off the uri
> branch (I hope that was where I was mucking about). I just yesterday
> got cpp-netlib building on my new laptop after a 9-month hiatus.
>
> - Kim
>

Thanks for the update  Are you still interested in contributing to the URI?
G

Re: [cpp-netlib-devel] URI and shipping 0.4

[Glyn M. <gly...@gm...>]

Hi John,

2009/10/1 John P. Feltz <jf...@ov...>

> I'm glad you posted the link, this basically is the first step of what
> needs to be decided upon for completion of this feature.


Thanks for doing this.


> I think my
> implementation is close in addressing the proposed requirements. At the
> moment it's lacking relative resolution and grammar from 1.1 (it's based
> off the 1.0 rfc, I think the differences are minor at the moment). I'm
> desiring an extensible uri parsing solution. While it is a bit of a
> departure from the the original protocol objectives of the library, It
> doesn't veer off too far as to become needless and wasteful.
> Nevertheless, I'm trying not to argue use of my implementation over
> another. The question is ultimately, if the requirements are common. If
> not, than  there are clear reasons to back a particular implementation.
>
>
The first issue with choosing one implementation over another is that we
have 3 and each has a different set of unit tests.  Each  can be found here:

https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/uri/libs/network/test/uri_test.cpp
https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/urllib-dean/libs/network/test/url_test.cpp
https://sourceforge.net/apps/trac/cpp-netlib/browser/branches/http_integration_jf/libs/uri/test/rfc3986_spirit_grammar.cpp

This suggests that everyone is working towards different goals, and the
first thing we should do is gather our unit tests so we can agree on what we
expect from a URI interface.

I think Dean's approach is biased towards HTTP (I think he intends to add
types to support e.g. smtp::uri, xmpp::uri etc. in the same way as he wants
to extend the request and response templates) and John's is aiming towards
matching the RFC specs as close as possible.  Is this a fair analysis?

G

Re: [cpp-netlib-devel] URI and shipping 0.4

[Kim G. <kim...@gm...>]

Hi Glyn,

On Wed, Sep 30, 2009 at 21:26, Glyn Matthews <gly...@gm...> wrote:
>
> I'd like to ask everyone who's working on something for C++ Networking
> Library to give me a status update.  I notice that some work is being done
> ondifferent branches and I'm a little concerned that there's duplicate
> effort going on, specifically for URI processing (I think there are at least
> 3 or 4 different implementations of URI parsers in various stages of
> completion).

I've abandoned my part in that, so we might as well kill off the uri
branch (I hope that was where I was mucking about). I just yesterday
got cpp-netlib building on my new laptop after a 9-month hiatus.

- Kim

Re: [cpp-netlib-devel] URI and shipping 0.4

[John P. F. <jf...@ov...>]

I'm glad you posted the link, this basically is the first step of what 
needs to be decided upon for completion of this feature. I think my 
implementation is close in addressing the proposed requirements. At the 
moment it's lacking relative resolution and grammar from 1.1 (it's based 
off the 1.0 rfc, I think the differences are minor at the moment). I'm 
desiring an extensible uri parsing solution. While it is a bit of a 
departure from the the original protocol objectives of the library, It 
doesn't veer off too far as to become needless and wasteful. 
Nevertheless, I'm trying not to argue use of my implementation over 
another. The question is ultimately, if the requirements are common. If 
not, than  there are clear reasons to back a particular implementation.

John

Glyn Matthews wrote:
> Hi netlibers,
>
>
> I'd like to ask everyone who's working on something for C++ Networking
> Library to give me a status update.  I notice that some work is being done
> ondifferent branches and I'm a little concerned that there's duplicate
> effort going on, specifically for URI processing (I think there are at least
> 3 or 4 different implementations of URI parsers in various stages of
> completion).
>
> A couple of months ago Dean suggested we start thinking about getting
> version 0.4 out of the door and I'd like to coordinate our efforts on this,
> and to release a reasonable quality, generic URI in the near future, so then
> we can concentrate on improvements and protocol implementations after that.
>
> References:
> https://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements
>
> Thanks,
> Glyn
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

[cpp-netlib-devel] URI and shipping 0.4

[Glyn M. <gly...@gm...>]

Hi netlibers,


I'd like to ask everyone who's working on something for C++ Networking
Library to give me a status update.  I notice that some work is being done
ondifferent branches and I'm a little concerned that there's duplicate
effort going on, specifically for URI processing (I think there are at least
3 or 4 different implementations of URI parsers in various stages of
completion).

A couple of months ago Dean suggested we start thinking about getting
version 0.4 out of the door and I'd like to coordinate our efforts on this,
and to release a reasonable quality, generic URI in the near future, so then
we can concentrate on improvements and protocol implementations after that.

References:
https://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements

Thanks,
Glyn

Re: [cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

[Kim G. <kim...@gm...>]

Hi Dean,

On Sun, Aug 23, 2009 at 12:24, Dean Michael
Berris<mik...@gm...> wrote:
>
> Makes sense... However, my only concern here is that the simplicity of
> using the free function parse_specific and relying on ADL to pick up
> the correct implementation.

Ah, I see -- the ADL overload aspect didn't occur to me.

> Although I guess it should be easy to make 'parse' a public static
> function so we don't have to instantiate the scheme_specific_parser<>.

Oops, yeah, that's what I meant -- I missed the 'static'. But does
that sort out the ADL-based implementation selection? We probably need
a wrapper function that delegates to the scheme_specific_parser, no?

> I like it! :D When do I expect a patch and passing tests? :D

Maybe when I have more than 6 continuous minutes/day of time to myself ;-)

- Kim

Re: [cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

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

Hi Kim!

On Sun, Aug 23, 2009 at 4:03 PM, Kim Gräsman<kim...@gm...> wrote:
> Hi Dean,
>
> On Fri, Aug 21, 2009 at 17:07, Dean Michael
> Berris<mik...@gm...> wrote:
>>
>> I understand -- I'm actually on the way to becoming a father myself
>> this November so I'm actually trying to get as much open source
>> programming time now before my first baby arrives. :D It would be
>> great to see you contributing to the testing and even the
>> implementation again. :)
>
> Congratulations!
>

Thanks. :)

>> Yes, I was actually struggling with this one -- if I go about it
>> through the overloading route, it would look something like this:
>>
>>  template <class Range>
>>  bool parse_specific(Range & range, tags::default_);
>>
>>  template <class Range>
>>  bool parse_specific(Range & range, tags::http);
>>
>> Which I think would work and would be worth a shot implementing. The
>> call to parse_specific then would look like:
>>
>>  parse_specific(range, Tag());
>>
>> In parse_url.
>
> Looking more closely, I'm not sure that can be made to work, as
> parse_specific's second param is an url_parts<Tag>&, derived from the
> template arg.
>

Oh right. Should it then be:

  template <class Range>
  bool parse_specific(Range & range, url_parts<tag::default_> & parts);

  template <class Range>
  bool parse_specific(Range & range, url_parts<tag::http> & parts);

or

  template <class Range>
  bool parse_specific(Range & range, url_parts<tag::default_> & parts,
tag::default_);

  template <class Range>
  bool parse_specific(Range & range, url_pars<tag::http> & parts, tag::http);

?

> We could overload on the entire url_parts<tag> type, but then there
> would be no way of accessing other types derived from the tag (e.g.
> string_type) inside the implementation.
>
> I think maybe the easiest -- accepting the strangeness of tag
> dispatching for a second ;-) -- would be to turn parse_specific into a
> class template, e.g. scheme_specific_parser, like so:
>
>  template< typename Range, typename Tag >
>  struct scheme_specific_parser
>  {
>     bool parse(Range& range, url_parts<Tag>& parts)
>     {
>         return true;
>     }
>  };
>
> Then we'd get rid of the problems with overload resolution and partial
> specialization wrt function templates entirely.
>

Makes sense... However, my only concern here is that the simplicity of
using the free function parse_specific and relying on ADL to pick up
the correct implementation.

Although I guess it should be easy to make 'parse' a public static
function so we don't have to instantiate the scheme_specific_parser<>.

I like it! :D When do I expect a patch and passing tests? :D

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

Re: [cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

[Kim G. <kim...@gm...>]

Hi Dean,

On Fri, Aug 21, 2009 at 17:07, Dean Michael
Berris<mik...@gm...> wrote:
>
> I understand -- I'm actually on the way to becoming a father myself
> this November so I'm actually trying to get as much open source
> programming time now before my first baby arrives. :D It would be
> great to see you contributing to the testing and even the
> implementation again. :)

Congratulations!

> Yes, I was actually struggling with this one -- if I go about it
> through the overloading route, it would look something like this:
>
>  template <class Range>
>  bool parse_specific(Range & range, tags::default_);
>
>  template <class Range>
>  bool parse_specific(Range & range, tags::http);
>
> Which I think would work and would be worth a shot implementing. The
> call to parse_specific then would look like:
>
>  parse_specific(range, Tag());
>
> In parse_url.

Looking more closely, I'm not sure that can be made to work, as
parse_specific's second param is an url_parts<Tag>&, derived from the
template arg.

We could overload on the entire url_parts<tag> type, but then there
would be no way of accessing other types derived from the tag (e.g.
string_type) inside the implementation.

I think maybe the easiest -- accepting the strangeness of tag
dispatching for a second ;-) -- would be to turn parse_specific into a
class template, e.g. scheme_specific_parser, like so:

  template< typename Range, typename Tag >
  struct scheme_specific_parser
  {
     bool parse(Range& range, url_parts<Tag>& parts)
     {
         return true;
     }
  };

Then we'd get rid of the problems with overload resolution and partial
specialization wrt function templates entirely.

- Kim

Re: [cpp-netlib-devel] [wiki] Updates to SoftwareSpecifications and MessageRequirements

[John P. F. <jf...@ov...>]

Dean Michael Berris wrote:
> If you feel strongly enough about it, re-write it in the format you
> want and I'll fill in the missing details that you want me to fill in.
>   
Fair enough. I'll rewrite what I can.
John

Re: [cpp-netlib-devel] [wiki] Updates to SoftwareSpecifications and MessageRequirements

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

Hi John,

On Sat, Aug 22, 2009 at 7:57 AM, John P. Feltz<jf...@ov...> wrote:
> I hate to be stickler on this, but we should come to a consensus on the
> format.

Why?

> IEEE-830-1998 and IEEE-1016-1998 are industry standards.

I think this makes sense if you're writing an _application_. Besides,
I've worked on so many software projects that didn't have industry
standard specifications. FWIW, these software projects got done and
delivered without relying on heavy "formal" documentation. Of course
YMMV.

For an open source project, I think we remain as fluid as possible.

Or, you can fill out the specifications with whatever format you like
-- I'll follow your lead on it if it makes it easier for you to do
things easily.

At the minimum I can give what I'd like the interface to the clients
to be Boost-style: documenting the concepts, documenting the functions
I expect to see, etc.

(Also, I don't have access to the official PDFs of these standards
having only ever heard of them today).

> They
> are essentially lingua franca for nearly every developer that I've come
> across.

I think we're hanging out with different types of developers. ;)

I've been dealing with agile software development practices for the
past 5 years, and so far I have yet to encounter a single formal
software requirement document based on anything taught in my Computer
Science classes; and these solutions have been delivered on time
delivering the features required. Not that I wouldn't know what to do
with one, but I'm saying it rarely needs to be that formal nor
"complete" at the beginning. Maybe if you're used to the "waterfall"
model, then you'd feel that the specifications would be required from
the beginning. I OTOH am not used to the waterfall model, and would
rather deliver according to what interface I intend the client to look
like while it's being used -- underneath, we can "wing it" and just
deliver what we feel would make sense.

Then, we release early, and release often -- or at least should do so.
We iterate. We can keep changing the implementation and the design and
everything but keep the client interface constant -- and that's all
there is to it. It's alright if we make mistakes and release something
that's broken, we'll just fix it in the next release.

Are you looking for just the client interface? Because right now, the
message::basic_message<> and http::basic_client<> interfaces are
pretty much going to be the same until 1.0 comes out. Code does the
talking. The tests are the requirements. New requirements mean new
tests. I can keep writing new tests and stop implementing too, but I
don't think that's a good use of my time. ;)

> From experience, I strongly feel that basic use of the concepts
> from 830, such as User Characteristics, Scope, Product Perspective, and
> Specific Requirements would be extremely beneficial for this project. I
> can't tell you how many times I've discovered overlooked aspects to
> something I was building by following those guidelines.
>

Sure, that's all fine and good if you're outsourcing work for a
product to be shipped and shrink-wrapped and never going to be
upgraded -- maybe if you're going to flash them onto devices, then you
really only have one chance at putting it in there. Requirements make
sense for these types of projects where you're meant to deliver just
one thing that would be required as it is (nuts, bolts, network
interfaces, realtime operating systems on non-reflashable ROM,
firmware on non-reflashable ROM, etc.).

I think drawing a line in the sand on the specification format isn't
something we should be doing -- but rather, let's put what you think
should be there and let's see how that works. Whether it's
industry-standard compliant documentation rarely means anything IMO
especially if it's the code that actually matters.

If you feel strongly enough about it, re-write it in the format you
want and I'll fill in the missing details that you want me to fill in.
(I should really subscribe to Wiki updates to these pages...)

HTH

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

Re: [cpp-netlib-devel] [wiki] Updates to SoftwareSpecifications and MessageRequirements

[John P. F. <jf...@ov...>]

I hate to be stickler on this, but we should come to a consensus on the 
format. IEEE-830-1998 and IEEE-1016-1998 are industry standards. They 
are essentially lingua franca for nearly every developer that I've come 
across. From experience, I strongly feel that basic use of the concepts 
from 830, such as User Characteristics, Scope, Product Perspective, and 
Specific Requirements would be extremely beneficial for this project. I 
can't tell you how many times I've discovered overlooked aspects to 
something I was building by following those guidelines.

John

Dean Michael Berris wrote:
> Hi Guys,
>
> I've made a few changes to the SoftwareSpecifications page and
> following John's structure for the page. I keep forgetting that you
> can have more than one page on a Wiki to put information in. ;)
>
> Anyway, I also made a new page where the MessageRequirements are put.
> However, note that this doesn't follow the same format that the
> HTTPAPIRequirements page proposes. I have yet to flesh out the other
> requirements pages, and I think these pages ought to be filled out by
> "users" of the library (or at least representative users). For one, I
> think I need to move the contents of MessageRequirements to
> MessageDesignSpecifications looking at the content of that page...
>
> What do you think guys? Comments would be most appreciated. :)
>
>   

[cpp-netlib-devel] [wiki] Updates to SoftwareSpecifications and MessageRequirements

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

Hi Guys,

I've made a few changes to the SoftwareSpecifications page and
following John's structure for the page. I keep forgetting that you
can have more than one page on a Wiki to put information in. ;)

Anyway, I also made a new page where the MessageRequirements are put.
However, note that this doesn't follow the same format that the
HTTPAPIRequirements page proposes. I have yet to flesh out the other
requirements pages, and I think these pages ought to be filled out by
"users" of the library (or at least representative users). For one, I
think I need to move the contents of MessageRequirements to
MessageDesignSpecifications looking at the content of that page...

What do you think guys? Comments would be most appreciated. :)

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

Re: [cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

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

On Fri, Aug 21, 2009 at 10:59 PM, Kim Gräsman<kim...@gm...> wrote:
[snip]
>
>> My approach is almost different from any approach that I've seen taken
>> as far as URL parsing is concerned -- using template functions and
>> template classes and a generic programming approach to specific URL
>> parsing. However mine is not as close to the RFC as I'd like, and is
>> not as well tested as I'd like either.
>>
>> Can us three gentlemen work together towards: 1) Adding better test
>> coverage 2) Implementing the details of the RFC and 3) Merging what we
>> can towards something that works and is release-ready?
>
> I'd love to help with the tests, but we've just had our second child
> and life with two kids doesn't leave much time for hacking :-) Let me
> see if I can help out, but don't count on it.
>

I understand -- I'm actually on the way to becoming a father myself
this November so I'm actually trying to get as much open source
programming time now before my first baby arrives. :D It would be
great to see you contributing to the testing and even the
implementation again. :)

> Quick question -- parse_specific seems to be a function template that
> you specialize on the Range and Tag. I thought specializing function
> templates was frowned upon, e.g. [1]...? Plus, as I understand it, you
> can't partially specialize it (reuse code parsers for one Range over
> several Tags). Can't you use simple overloading to get the same
> result? I can't claim to understand it in detail, I just browsed the
> code quickly, but this jumped out at me.
>

Yes, I was actually struggling with this one -- if I go about it
through the overloading route, it would look something like this:

  template <class Range>
  bool parse_specific(Range & range, tags::default_);

  template <class Range>
  bool parse_specific(Range & range, tags::http);

Which I think would work and would be worth a shot implementing. The
call to parse_specific then would look like:

  parse_specific(range, Tag());

In parse_url.

If you can make the changes and make sure the tests pass, that would
be super. :)

> Thanks,

You're welcome, and thank you for pointing out a better way at
approaching parse_specific. :D

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

Re: [cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

[Kim G. <kim...@gm...>]

Hi Dean,

On Fri, Aug 21, 2009 at 11:10, Dean Michael
Berris<mik...@gm...> wrote:
>
> Kim's attempt was more of an OO approach (please correct me if I'm
> wrong Kim), something that I felt was too "simple" and could also be
> done with just static polymorphism.

Yes, that's a fair assessment.

> My approach is almost different from any approach that I've seen taken
> as far as URL parsing is concerned -- using template functions and
> template classes and a generic programming approach to specific URL
> parsing. However mine is not as close to the RFC as I'd like, and is
> not as well tested as I'd like either.
>
> Can us three gentlemen work together towards: 1) Adding better test
> coverage 2) Implementing the details of the RFC and 3) Merging what we
> can towards something that works and is release-ready?

I'd love to help with the tests, but we've just had our second child
and life with two kids doesn't leave much time for hacking :-) Let me
see if I can help out, but don't count on it.

Quick question -- parse_specific seems to be a function template that
you specialize on the Range and Tag. I thought specializing function
templates was frowned upon, e.g. [1]...? Plus, as I understand it, you
can't partially specialize it (reuse code parsers for one Range over
several Tags). Can't you use simple overloading to get the same
result? I can't claim to understand it in detail, I just browsed the
code quickly, but this jumped out at me.

Thanks,
- Kim

[1] http://www.gotw.ca/publications/mill17.htm

Re: [cpp-netlib-devel] [admin] Adding Developer List as Drop-down items in Trac?

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

On Fri, Aug 21, 2009 at 10:37 PM, Glyn Matthews<gly...@gm...> wrote:
>
> Yep: https://sourceforge.net/apps/trac/cpp-netlib/admin
>
> You and Mike already have admin permissions.  The milestones I've already
> added are not correct, they should correspond to intended releases.
>

Sweetness! Now I've changed a few things around in the configuration
to suit my personal taste of how the project settings would look like.
Thoughts and suggestions would be very much appreciated. :)

Have a good one guys! :D

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

Re: [cpp-netlib-devel] [admin] Adding Developer List as Drop-down items in Trac?

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/8/21 Dean Michael Berris <mik...@gm...>

> Hi Glyn/Mike,
>
> Do either of you know how to get the developer list into a drop-down
> item in the Trac ticket filing form? How about addition of milestones?
> How about default assignees for components? Is there a web-based admin
> interface to our Trac installation?
>

Yep: https://sourceforge.net/apps/trac/cpp-netlib/admin

You and Mike already have admin permissions.  The milestones I've already
added are not correct, they should correspond to intended releases.



>
> TIA :D
>

YW

G

[cpp-netlib-devel] [admin] Adding Developer List as Drop-down items in Trac?

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

Hi Glyn/Mike,

Do either of you know how to get the developer list into a drop-down
item in the Trac ticket filing form? How about addition of milestones?
How about default assignees for components? Is there a web-based admin
interface to our Trac installation?

TIA :D

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

Re: [cpp-netlib-devel] BCCL Checks in branches/urllib-dean

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

On Fri, Aug 21, 2009 at 8:51 PM, Glyn Matthews<gly...@gm...> wrote:
> Hi Dean,
>
> 2009/8/21 Dean Michael Berris <mik...@gm...>
>>
>> Hi Guys!
>>
>> Glyn, do you have a template for the document that will describe the
>> Url and HttpUrl Concepts?
>
> Nope, not yet but I created a ticket so I'll do it when I can.

Oh right, we have Trac!

I'll file my next steps too, that's a nice idea... Thanks for bringing
it up (again)! :D

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

Re: [cpp-netlib-devel] BCCL Checks in branches/urllib-dean

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/8/21 Dean Michael Berris <mik...@gm...>

> Hi Guys!
>
> Glyn, do you have a template for the document that will describe the
> Url and HttpUrl Concepts?
>

Nope, not yet but I created a ticket so I'll do it when I can.
G

[cpp-netlib-devel] BCCL Checks in branches/urllib-dean

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

Hi Guys!

In the hopes of making the URL parsing library implementation
Concept-aware, I've implemented some concept checking classes and
concept assertions in the implementation. This is in preparation for
making generic algorithms that operate on URLs. You can see the
changes in branches/urllib-dean -- this is in preparation to making
the URL library a generic enough library of algorithms.

What could these algorithms be you ask? Well, one that comes to mind
is rendering: printing a URL in a specific format.

Do you know other algorithms that can be applied to URLs? Of course,
that's aside from the access functions... If so, let me know so I can
start implementing those too.

For the meantime, I intend to make the http::message's constructor
templated on the type of the URL, and require that the type model the
HttpUrl concept.

Glyn, do you have a template for the document that will describe the
Url and HttpUrl Concepts?

Thanks guys and I hope this helps!

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

[cpp-netlib-devel] Merge to Trunk, Preparing for the Pain

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

Hi Guys,

I see that John has done quite a lot of work already in his branch(es)
and I'd like to get a release out (0.4) that will have some support
for persistent connections and a limited (partially correct) HTTP URL
parser, and along with it support for HTTPS. Having said this, I have
two major issues to deal with and it has something to do with some
major parts of the library moving forward.

URI/URL Parsing:

I see that there have already been three attempts at a URI/URL parsing
library (one from Kim, one from John, and one from me).

Kim's attempt was more of an OO approach (please correct me if I'm
wrong Kim), something that I felt was too "simple" and could also be
done with just static polymorphism.

John's approach has been in progress for a while now, uses
Spirit.Classic, and adheres to the RFC's almost to the letter from
what I've seen (given the EBNF).

My approach is almost different from any approach that I've seen taken
as far as URL parsing is concerned -- using template functions and
template classes and a generic programming approach to specific URL
parsing. However mine is not as close to the RFC as I'd like, and is
not as well tested as I'd like either.

Can us three gentlemen work together towards: 1) Adding better test
coverage 2) Implementing the details of the RFC and 3) Merging what we
can towards something that works and is release-ready?

My criteria for a release-ready URI/URL parsing library are:
  * Something that can stand on its own and is able to handle HTTP(S)
URLs with encoded characters left alone
  * A URL encoding function/library that will turn a string into a URL
encoded string
  * Well documented library (concepts used, internal implementation,
and nice readable user examples).

HTTPS handling:

John has started implementing persistent connections using a
policy-based design that will actually change the innards of the
current HTTP client. I can see that his approach (although a bit
verbose for my taste) actually works semantically separating the
connection management from the client implementation. I do have some
issues with this approach breaking the simplicity of the client
interface for users. Part of the HTTPS effort includes delegating
connection management to a subsystem or component that determines what
kind of connection or which persisting connection is used to service a
request -- if it sees an https scheme then it's a matter of creating
an SSL socket to the specified port on the destination host and then
piping the already crafted HTTP request.

Now the way I imagine doing this is through some connection_manager
type which based on runtime variables will be able to create the
appropriate connection type -- and if HTTP 1.1 was to be supported,
also maintain connections that do support the default persistent
connection in HTTP 1.1. This connection_manager can be encapsulated in
the http::client so that the users don't have to worry about it.
However, the choice of what specific *kind* of manager to instantiate
is a client initialization setting. Something like this in client
code:

  http::client c(http::follow_redirects, http::persistent, http::pipelined);
  http::response r = c.get("https://cpp-netlib.sourceforge.net/yaddayadda");

Inside the http::client class, would be something like this:

  template <...> struct client {
  private:
    shared_ptr<connection_manager> manager;
  public:
    client(...)
    : manager(
        connection_manager_factory::create_manager(
        /* client constructor parameters? */
        )
      )
    {}
    // ...
  };

Then from within the connection_manager interface would be something like this:

  struct connection_manager {
    virtual shared_ptr<connection> get_connection(host, port);
    virtual void put_connection(shared_ptr<connection>);
  };

A connection type would then be the one handling the wire protocol
implementation (supporting gzip for example, handling mime types,
etc.). Maybe with this design we may even be able to implement
stream-like response objects which have support for chunked-reading of
data. With C++0x we may be able to get away with code like this on the
client side:

  http::client c(/* init options */);
  auto stream = c.get("http://some.site.com/streamed", http::streamed)
  while (true) {
    auto chunk = read(stream, 1024); // will block read 1KB of the
body being streamed
    if (size(chunk) > 0) { /* deal with the chunk */ }
    else break;
  }

I'd even like to support Iterator/Range semantics too:

  http::client c(/* init options */);
  auto stream = c.get("http://some.site.com/streamed", http::streamed);
  copy(begin(stream), end(stream), ostream_iterator<char>(cout, ""));

At this stage of the game though it's going to need some work to be
done to get to this level of expressiveness and simplicity on the
client side. Internally though we can go as complex and powerful as we
may want, but the premium has to be put on the client code being easy
to read and write.

Sorry for the long post, but do you guys think we can get something
done in this front that we can merge to trunk then have it released as
version 0.4?

Hope to hear from you soon!

(BTW, please feel free to respond and change the subject line to
indicate which part of this post you're responding to -- I didn't feel
like sending a lot of emails with disparate topics being discussed in
different emails because I felt this is all related in some manner.
Thanks for understanding. :D)

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

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

[John P. F. <jf...@ov...>]

Edited. Note that ProjectRequirements has been moved to ProjectCharter. 
I'm leaning towards this structure:
main page
 -project charter
 -specifications
 --HTTP requirements+design spec
 --Other protocol..
 --Message..
 --MIME..
 --URI etc

I'll continue to work on the HTTP/URI angle of the spec's.

John

Glyn Matthews wrote:
> Hi John,
>
> 2009/8/16 John P. Feltz <jf...@ov...>
>
>   
>> I don't disagree with your points. This mailing list is vital for
>> supporting the library and discussing certain things about it. However,
>> concerning debate over design and requirements, I would like to suggest
>> that a resource such as a wiki be sought first, provided there are clear
>> efforts to maintain some form of conceptual integrity (the person in
>> charge, basically), and that we use a standard format(IEEE 830 for
>> instance). I was dissatisfied with the original layout and content of
>> the wiki on the original sf.net site, and decided that coding would be a
>> better use of my time. I now think that was a mistake. I think this
>> project suffers from insufficient requirements and design specification
>> (I am partly to blame for this), and those two items should be addressed
>> before we move forward. So is this really about the mailing list?
>> Probably not. I think it's more about under-utilized specifications and
>> a lack of discourse about them, which has lead myself and possibly
>> others at times to feel lost about the direction of this project.
>>     
>
>
>
> Right, 100% agreed.  It's very difficult to see how to proceed without some
> kind of roadmap or vision for what we think this project should become.  I
> think that Trac is a great improvement over the old sf wiki so we should
> take advantage of this.  I've already added two empty pages (one each for
> requirements and specification), so at least we can discuss and document
> this.
>
> I added some pages to the wiki for these:
> http://sourceforge.net/apps/trac/cpp-netlib/wiki/ProjectRequirements
> http://sourceforge.net/apps/trac/cpp-netlib/wiki/SoftwareSpecification
>
> Please comment.
>
> G
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

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

[Allister L. S. <all...@gm...>]

Hi Dean,
(I decided it'd be more appropriate to reply to this thread instead of the
previous thread.)
Here's the link to request for a Google Wave account:
http://code.google.com/apis/wave/
For now, I'll read the docs you've written and see how I can continue to
contribute.

Cheers,
Allister

On Mon, Aug 17, 2009 at 4:09 PM, Dean Michael Berris <mik...@gm...
> wrote:

> And it is done -- I've put my thoughts into the two wiki pages. I'll
> add more as I go along.
>
> I hope I can be clearer in the documents, but I fully intend to flesh
> them out more in the coming days.
>
> HTH!
>
> http://sourceforge.net/apps/trac/cpp-netlib/wiki/ProjectRequirements
> http://sourceforge.net/apps/trac/cpp-netlib/wiki/SoftwareSpecification
>
> --
> Dean Michael Berris
> blog.cplusplus-soup.com | twitter.com/mikhailberis
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

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

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

And it is done -- I've put my thoughts into the two wiki pages. I'll
add more as I go along.

I hope I can be clearer in the documents, but I fully intend to flesh
them out more in the coming days.

HTH!

http://sourceforge.net/apps/trac/cpp-netlib/wiki/ProjectRequirements
http://sourceforge.net/apps/trac/cpp-netlib/wiki/SoftwareSpecification

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