cpp-netlib-devel Mailing List for C++ Network Library (Page 43)

Status: Alpha

Brought to you by: glynos, mikedickey, mikhail_beris

cpp-netlib-devel — Developers Mailing List

You can subscribe to this list here.

2007	Jan	Feb	Mar	Apr	May (52)	Jun (30)	Jul (17)	Aug (9)	Sep (4)	Oct (7)	Nov (11)	Dec (19)
2008	Jan	Feb (1)	Mar (37)	Apr (28)	May (15)	Jun (28)	Jul (7)	Aug (125)	Sep (116)	Oct (85)	Nov (14)	Dec (6)
2009	Jan (11)	Feb (4)	Mar (5)	Apr	May (9)	Jun (5)	Jul (4)	Aug (40)	Sep (1)	Oct (19)	Nov (43)	Dec (45)
2010	Jan (76)	Feb (95)	Mar (3)	Apr (23)	May (39)	Jun (54)	Jul (6)	Aug (13)	Sep (12)	Oct (59)	Nov (53)	Dec (43)
2011	Jan (43)	Feb (44)	Mar (25)	Apr (23)	May	Jun	Jul	Aug	Sep (5)	Oct (1)	Nov (2)	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (6)	Oct	Nov	Dec

Flat | Threaded

<< < 1 .. 41 42 43 44 45 .. 57 > >> (Page 43 of 57)

Re: [cpp-netlib-devel] Comments about the HTTP client interface

From: Divye K. <div...@gm...> - 2008-08-27 17:01:23

On Wed, Aug 27, 2008 at 6:14 PM, Glyn Matthews <gly...@gm...>wrote:

> Hello,
>
>
> I have some questions about the way HTTP requests are made using the
> current interface, specifically this (taken from the http_1_0_test.cpp):
>
>     using namespace boost::network;
>     http::request request("http://www.boost.org/");
>     http::client client_;
>     http::response response_;
>     response_ = client_.get(request);
>
>
> What exactly is the role of the client here?  I'm a little confused by the
> syntax because it reads as though you're trying to make a get request to an
> HTTP client.  Would it perhaps be better to rename http::client to
> http::connection?
>

Currently, I read the above code as:
1. frame a request for resource http://www.boost.org/
2. Create a client that handles http requests/responses
3. Get the resource specified by the request and provide a response.

However, I do admit that client.head(request) and client.put(request) don't
seem to be too intuitive in that respect.

> Secondly, why is the domain passed as an argument to the http::request
> constructor?  To me, this doesn't feel like the right unit of encapsulation.
>
> Does the following example code make more sense?
>
>     using namespace boost::network;
>     http::connection c("http://www.boost.org");
>     http::request request1("/users/news/version_1_36_0");
>     http::response response1 = c.get(request);
>     http::request request2("/cgi-bin/path");
>     request2 << body("post_body");
>     http::response response2 = c.post(request2);
>
> Two observations about this:
> The current implementation creates a new socket for each request that is
> made, whereas the above suggestion allows a socket to remain open for
> multiple requests.  Additionally, the URI processing is currently done
> inside the request constructor.  I think it would be better to re-factor
> this into a separate package.
>
> Any thoughts?
>

Glyn

I agree with the plus point of having a socket remain open for multiple
requests but the syntax suggested seems to separate the domain name and the
relative path of the resource. I wouldn't like to keep track of which domain
is associated with which domain. Also, this breaks encapsulation because a
function that takes only a http::request cannot determine where the resource
is located and which protocol is to be used. A part of that useful
information lies in the connection object. In my head, a resource is
completely specified only when its complete url/uri is available and in that
respect, the request object is underspecified.

Just my thoughts,
Divye

-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com

[cpp-netlib-devel] Comments about the HTTP client interface

From: Glyn M. <gly...@gm...> - 2008-08-27 12:44:32

Hello,


I have some questions about the way HTTP requests are made using the current
interface, specifically this (taken from the http_1_0_test.cpp):

    using namespace boost::network;
    http::request request("http://www.boost.org/");
    http::client client_;
    http::response response_;
    response_ = client_.get(request);


What exactly is the role of the client here?  I'm a little confused by the
syntax because it reads as though you're trying to make a get request to an
HTTP client.  Would it perhaps be better to rename http::client to
http::connection?

Secondly, why is the domain passed as an argument to the http::request
constructor?  To me, this doesn't feel like the right unit of encapsulation.

Does the following example code make more sense?

    using namespace boost::network;
    http::connection c("http://www.boost.org");
    http::request request1("/users/news/version_1_36_0");
    http::response response1 = c.get(request);
    http::request request2("/cgi-bin/path");
    request2 << body("post_body");
    http::response response2 = c.post(request2);

Two observations about this:
The current implementation creates a new socket for each request that is
made, whereas the above suggestion allows a socket to remain open for
multiple requests.  Additionally, the URI processing is currently done
inside the request constructor.  I think it would be better to re-factor
this into a separate package.

Any thoughts?

Glyn

Re: [cpp-netlib-devel] Release Early, Release Often

From: Dean M. B. <mik...@gm...> - 2008-08-26 08:00:37

On Tue, Aug 26, 2008 at 3:48 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi,
>
> 2008/8/26 Dean Michael Berris <mik...@gm...>
>>
>> Hi Everyone,
>>
>> I've just recently packaged the trunk snapshot revision #72 as
>> cpp-netlib-0.1 -- this does not include the documentation we already
>> have in the docs branch, and will only be available as a very early
>> alpha release.
>
> Cool :)  Is it possible that you could also tag this release in subversion?
> e.g. copy the current trunk to tags/0-1-alpha ?
>

Good idea. :) Let me do that. :D

>>
>> Question to the whole group: would anybody like to manage the release
>> process, and be the "official" release manager? For the meantime I'm
>> willing to take on this task but I imagine with the coding I'm still
>> supposed to do, is anybody willing to take on this responsibility?
>
> If no-one else volunteers, I'll do this.  What work will this mean?  I guess
> its:
>
> Managing trunk to ensure that it's stable;
> When the manager is confident of this, tag and package a release;
> Update the SF & wiki to publicise this
>

Precisely. It's more actually just creating tarballs and zips and
uploading the files to Subversion.

> How often do you expect releases?  You mention that you hope to have 0.2 out
> within a week, but the history of this project shows that weekly releases is
> a bit too ambitious.  But I don't see too much difficulty with an "as and
> when" approach at this early stage.
>

Right. Given that it's still in the flux/alpha state, I want to be
able to ship as early as possible. I mean, since we can run the unit
tests on our machines without having to wait for a lot of turnaround
time, I don't see much point in waiting too long yet. We can keep
releasing 0.2, 0.3, ..., 0.99, until we have a suitably usable 1.0
that we can present at a convention like BoostCon or something
similar. ;)

I imagine not giving much support for released alpha packages, but I
would love to get a package that people can start getting and trying
out or criticizing. Once we've got that critical feedback we need from
users, it's easier to move and come up with a more formal process.
Right now I think having something that works out sooner is better
than not having anything out there yet.

Getting a package out there as well allows us to get users to file
bugs and maybe entice people to actually contribute to the project
too. At least that's the intention. ;)

>> Have a good day everyone, and I hope this helps.
>
> Yes, thanks Dean.

You're welcome. :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Release Early, Release Often

From: Glyn M. <gly...@gm...> - 2008-08-26 07:48:41

Hi,

2008/8/26 Dean Michael Berris <mik...@gm...>

> Hi Everyone,
>
> I've just recently packaged the trunk snapshot revision #72 as
> cpp-netlib-0.1 -- this does not include the documentation we already
> have in the docs branch, and will only be available as a very early
> alpha release.


Cool :)  Is it possible that you could also tag this release in subversion?
e.g. copy the current trunk to tags/0-1-alpha ?


> Question to the whole group: would anybody like to manage the release
> process, and be the "official" release manager? For the meantime I'm
> willing to take on this task but I imagine with the coding I'm still
> supposed to do, is anybody willing to take on this responsibility?
>

If no-one else volunteers, I'll do this.  What work will this mean?  I guess
its:

Managing trunk to ensure that it's stable;
When the manager is confident of this, tag and package a release;
Update the SF & wiki to publicise this

How often do you expect releases?  You mention that you hope to have 0.2 out
within a week, but the history of this project shows that weekly releases is
a bit too ambitious.  But I don't see too much difficulty with an "as and
when" approach at this early stage.

Have a good day everyone, and I hope this helps.

Yes, thanks Dean.
G

Re: [cpp-netlib-devel] Latest docs (Was Re: Merging http_integration to trunk?)

From: Dean M. B. <mik...@gm...> - 2008-08-26 07:38:42

Hi Glyn,

On Tue, Aug 26, 2008 at 3:33 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/8/26 Dean Michael Berris <mik...@gm...>
>>
>> Glyn, do you think we should merge whatever you have in the
>> documentation into the trunk as well before we create the alpha
>> package?
>
> I've added a bit, but its more of a skeleton without much in the way of
> content, so I wouldn't feel confident with it in a release at this stage.
>
> The skeleton is based on the loose documentation we already have on the wiki
> and in the README file.  I'd like to expand the rationale, overview and the
> message type documentation first.  Do you think there's anything missing?
> Feel free to add missing sections in the docs branch.  I'll take the time to
> write more over the next week.
>

Okay, I'll get to the documentation soon as I get free cycles from
actual coding. ;)

At any rate, I'll see what I can add to the documentation over the
coming days. I'm front-loading my week so that the latter part I can
concentrate more on the lighter tasks and get better rest on the
weekend.

Or at least that's what I'm going to try and do. ;)

Thanks!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

[cpp-netlib-devel] Latest docs (Was Re: Merging http_integration to trunk?)

From: Glyn M. <gly...@gm...> - 2008-08-26 07:33:43

Hi Dean,

2008/8/26 Dean Michael Berris <mik...@gm...>

> Hi Everyone,
>
> Just a heads up, I've merged http_integration from 1-71 to trunk. This
> is now in revision 72.
>
> I'll soon be packaging an alpha version of the software.
>
> Glyn, do you think we should merge whatever you have in the
> documentation into the trunk as well before we create the alpha
> package?


I've added a bit, but its more of a skeleton without much in the way of
content, so I wouldn't feel confident with it in a release at this stage.

The skeleton is based on the loose documentation we already have on the wiki
and in the README file.  I'd like to expand the rationale, overview and the
message type documentation first.  Do you think there's anything missing?
Feel free to add missing sections in the docs branch.  I'll take the time to
write more over the next week.

G

[cpp-netlib-devel] Release Early, Release Often

From: Dean M. B. <mik...@gm...> - 2008-08-26 06:16:23

Hi Everyone,

I've just recently packaged the trunk snapshot revision #72 as
cpp-netlib-0.1 -- this does not include the documentation we already
have in the docs branch, and will only be available as a very early
alpha release.

The next release goal is next week 0.2 which should contain:

1. early documentation snapshot
2. more unit tests
3. HTTP 1.0 asynchronous get support

I'm working on item #3 which I should be committing to
http_integration pretty soon and then merging back into trunk as well
before the release scheduled next week Monday PDT.

If you would like to have your code included in the 0.2 release,
please let me know.

Question to the whole group: would anybody like to manage the release
process, and be the "official" release manager? For the meantime I'm
willing to take on this task but I imagine with the coding I'm still
supposed to do, is anybody willing to take on this responsibility?

Have a good day everyone, and I hope this helps.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.