cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[<rhy...@gm...>]

Hi,

Always glad to see progress :-) I've checked the code under a Debian 
Linux box with Boost trunk, and it fails to compile, since pthread is 
required by Boost.System. It is fairly easy to cope with. Add this line 
to the trunk/libs/network/test/Jamfile.v2 file in the project requirements:

    <toolset>gcc:<source>pthread

Then the code compiles. But, I got linking errors, and I've got no idea 
how to settle them:

...failed gcc.link 
libs/network/test/bin/gcc-4.1.3/debug/link-static/message_transform_test...
...skipped 
<plibs/network/test/bin/gcc-4.1.3/debug/link-static>message_transform_test.passed 
for lack of 
<plibs/network/test/bin/gcc-4.1.3/debug/link-static>message_transform_test...
gcc.compile.c++ 
libs/network/test/bin/gcc-4.1.3/debug/link-static/http_1_0_test.o
gcc.link libs/network/test/bin/gcc-4.1.3/debug/link-static/http_1_0_test
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-write.o): 
In function `__write_nocancel':
(.text+0x26): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-write.o): 
In function `__write_nocancel':
(.text+0x56): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-close.o): 
In function `__close_nocancel':
(.text+0x20): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-close.o): 
In function `__close_nocancel':
(.text+0x4b): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-connect.o): 
In function `__connect':
(.text+0x23): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-connect.o):(.text+0x52): 
more undefined references to `__syscall_error' follow
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(sigaction.o): 
In function `__libc_sigaction':
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/../sysdeps/unix/sysv/linux/i386/sigaction.c:83: 
undefined reference to `_dl_sysinfo_dso'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/../sysdeps/unix/sysv/linux/i386/sigaction.c:83: 
undefined reference to `_dl_sysinfo_dso'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(init.o): 
In function `__pthread_initialize_minimal_internal':
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/init.c:264: 
undefined reference to `__libc_setup_tls'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/init.c:387: 
undefined reference to `_dl_init_static_tls'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/init.c:389: 
undefined reference to `_dl_wait_lookup_done'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(pthread_create.o): 
In function `allocate_stack':
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/allocatestack.c:411: 
undefined reference to `_dl_stack_flags'
/build/buildd/glibc-2.6.1/build-tree/glibc-2.6.1/nptl/allocatestack.c:547: 
undefined reference to `_dl_stack_flags'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-read.o): 
In function `__read_nocancel':
(.text+0x26): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-read.o): 
In function `__read_nocancel':
(.text+0x56): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-open.o): 
In function `__open_nocancel':
(.text+0x26): undefined reference to `__syscall_error'
/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libpthread.a(ptw-open.o): 
In function `__open_nocancel':
(.text+0x56): undefined reference to `__syscall_error'



Dean Michael Berris wrote:
> Hi Guys,
>
> I know, it's been a while. However now I just got myself a spanking
> new machine on which I can do the development of the network library
> on -- without having to interfere with the work I do. This gives me a
> reason to 1) go home earlier and 2) develop the network library more.
>
> Now that I'm pretty much setting up the dispatcher library I've been
> working on for review in the near future (am waiting for a
> considerably important enhancement to Boost.Function to get that
> going, while it's not there yet I'm setting my eyes on low hanging
> fruit) I'm looking forward to getting some things done quickly as far
> as the network library is concerned.
>
> I certainly hope interest hasn't waned yet. I know mine hasn't, and I
> just hope we can get at least 1.0 released before the end of the year.
>
> As for the subject, I'm not an SVN expert -- do you guys know how to
> branch, switch to the branch, continue developing code there (possibly
> broken stuff), and then later merge back the changes to trunk? And
> what do you suggest for the branching convention, so that those who
> are interested in branching off and working on stuff will be able to
> do so without having to deal with too many issues later?
>
> I hope to be able to check in the (crude) HTTP 1.0 client
> implementation in a while. I'll send another email when I'm done. For
> the meantime, I'm going to be checking code into the trunk, of course
> still making sure that the tests aren't broken.
>
> Have a great day everyone (evening from here), and I certainly hope to
> hear from you soon!
>
>   

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

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

Hey Glyn!

On 10/8/07, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 08/10/2007, Dean Michael Berris <mik...@gm...> wrote:
>
> I certainly hope interest hasn't waned yet. I know mine hasn't, and I
> just hope we can get at least 1.0 released before the end of the year.
>
> Interest hasn't waned ;)  I'm glad to see something happening.

Now I'm glad we're getting somewhere. ;)

Let me get it out of the way first, you may now update to revision 23
-- this has been built against the latest Boost trunk. Please let me
know if you encounter problems though, I'm developing on Windows using
MSVC 8.0 Express Edition. I currently do not have access to a Linux
machine, so whoever can run and patch for GCC on that platform would
be very welcome. :)

> > As for the subject, I'm not an SVN expert -- do you guys know how to
> > branch, switch to the branch, continue developing code there (possibly
> > broken stuff), and then later merge back the changes to trunk? And
> > what do you suggest for the branching convention, so that those who
> > are interested in branching off and working on stuff will be able to
> > do so without having to deal with too many issues later?
>
> For such a small group as ourselves, I'm comfortable with the standard SVN
> convention for branches, with (as far as is possible) branches representing
> distinct tasks:
>
> |- cpp-netlib
>   |- trunk
>   |- branches
>     |- http
>     |- dns
>     |- other_clever_stuff
>   |- tags
>
> I think the naming of the branches should represent the tasks rather than
> the identity of the person working on it.  As for integration, maybe this
> responsibility could be given to one individual who people would notify when
> their branch is stable.  They would identify any problems and use the SF
> tracker to update the relevant people of breakages.  I don't think this will
> be a huge amount of work.
>

I completely agree with this. Next time I'm up to something, I'll
branch according to what that something is as well. :)

> > I hope to be able to check in the (crude) HTTP 1.0 client
> > implementation in a while. I'll send another email when I'm done. For
> > the meantime, I'm going to be checking code into the trunk, of course
> > still making sure that the tests aren't broken.
>
> That's OK for now, since there's really only your own branch being worked
> on.
> > Have a great day everyone (evening from here), and I certainly hope to
> > hear from you soon!
>
> Good to hear from you too.  I'll take a look at the code later and I'll give
> you more feedback.

Please do! They're available now from the trunk.

Have a great day everyone, and have fun!

(Note, please help me complete the unit test for HTTP 1.0 -- the
parser is implemented with Boost.Spirit, and if anybody's got time to
make that implementation a bit more sane than it currently is, help is
definitely most wanted. The parsing happens at construction of the
http::request object. I'm also already using Fusion which may up the
compile time if you're going to be using the simple HTTP client.)

Hope to commit more tomorrow. At the moment, I'm going to get some
much needed sleep. :)

Have a great day guys, and have fun with this! :)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

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

Hi Dean,

On 08/10/2007, Dean Michael Berris <mik...@gm...> wrote:

I certainly hope interest hasn't waned yet. I know mine hasn't, and I
just hope we can get at least 1.0 released before the end of the year.
Interest hasn't waned ;)  I'm glad to see something happening.

As for the subject, I'm not an SVN expert -- do you guys know how to
> branch, switch to the branch, continue developing code there (possibly
> broken stuff), and then later merge back the changes to trunk? And
> what do you suggest for the branching convention, so that those who
> are interested in branching off and working on stuff will be able to
> do so without having to deal with too many issues later?


For such a small group as ourselves, I'm comfortable with the standard SVN
convention for branches, with (as far as is possible) branches representing
distinct tasks:

|- cpp-netlib
  |- trunk
  |- branches
    |- http
    |- dns
    |- other_clever_stuff
  |- tags

I think the naming of the branches should represent the tasks rather than
the identity of the person working on it.  As for integration, maybe this
responsibility could be given to one individual who people would notify when
their branch is stable.  They would identify any problems and use the SF
tracker to update the relevant people of breakages.  I don't think this will
be a huge amount of work.


> I hope to be able to check in the (crude) HTTP 1.0 client
> implementation in a while. I'll send another email when I'm done. For
> the meantime, I'm going to be checking code into the trunk, of course
> still making sure that the tests aren't broken.


That's OK for now, since there's really only your own branch being worked
on.

Have a great day everyone (evening from here), and I certainly hope to
> hear from you soon!


Good to hear from you too.  I'll take a look at the code later and I'll give
you more feedback.

G

[cpp-netlib-devel] Branching to Implement HTTP 1.0

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

Hi Guys,

I know, it's been a while. However now I just got myself a spanking
new machine on which I can do the development of the network library
on -- without having to interfere with the work I do. This gives me a
reason to 1) go home earlier and 2) develop the network library more.

Now that I'm pretty much setting up the dispatcher library I've been
working on for review in the near future (am waiting for a
considerably important enhancement to Boost.Function to get that
going, while it's not there yet I'm setting my eyes on low hanging
fruit) I'm looking forward to getting some things done quickly as far
as the network library is concerned.

I certainly hope interest hasn't waned yet. I know mine hasn't, and I
just hope we can get at least 1.0 released before the end of the year.

As for the subject, I'm not an SVN expert -- do you guys know how to
branch, switch to the branch, continue developing code there (possibly
broken stuff), and then later merge back the changes to trunk? And
what do you suggest for the branching convention, so that those who
are interested in branching off and working on stuff will be able to
do so without having to deal with too many issues later?

I hope to be able to check in the (crude) HTTP 1.0 client
implementation in a while. I'll send another email when I'm done. For
the meantime, I'm going to be checking code into the trunk, of course
still making sure that the tests aren't broken.

Have a great day everyone (evening from here), and I certainly hope to
hear from you soon!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] POCO library

[Michael D. <mi...@mi...>]

Hi Glyn,

I have never used the library myself but I did look at it several months 
ago before finding boost-asio.  It seems quite solid, and I didn't 
realize before that they had adopted a boost license..

Poco has its own implementation for all your standard low-level 
networking code (TCP sockets, datagrams, etc).  So far as I can tell, 
there is no support for asynchronous operations (which avoids 
sleepy/blocking threads).  This overlaps the boost-asio library, which 
implements all your low-level code, supports asynchronous operations, 
and will be included in the next (1.35.0) boost release (it's currently 
in trunk).

What poco has that boost-asio doesn't is the higher-level protocol 
support (HTTP, SMTP, ICMP, etc).  There are a few examples that 
implement basic protocols in the boost-asio distribution, but they are 
not very robust or included as part of the library itself.

My understanding is that the purpose of this project is to add that 
higher-level protocol support on top of boost-asio, and ultimately to 
have it included as part of the boost mainline distribution.  Although 
poco uses the boost license, it's an independent project in the same way 
that libpion (http://atomiclabs.com/libpion) is.  I think it would be 
great if we could all collaborate together to make use of what work has 
already been done.  Has anyone spoken with the poco authors about this?

Take care,
-Mike


Glyn Matthews wrote:
> Hi Guys,
>
>
> My colleagues are using Poco 
> (http://www.appinf.com/poco/info/index.html ) in a project, and I 
> discovered that the core library has a boost licence.  Does anyone 
> have any more information on this?  What are your thoughts on this 
> with respect to this project?
>
> Cheers,
> Glyn
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

[cpp-netlib-devel] POCO library

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

Hi Guys,


My colleagues are using Poco (http://www.appinf.com/poco/info/index.html )
in a project, and I discovered that the core library has a boost licence.
Does anyone have any more information on this?  What are your thoughts on
this with respect to this project?

Cheers,
Glyn

Re: [cpp-netlib-devel] hello

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

Hi Tim!

On 8/31/07, Tim Weiler <tim...@gm...> wrote:
> Hello,
>
> I'm interested in finding out if there is any value I can add to this
> effort.  For now I'll just hang out for a bit and watch what is going on.
> And throw in a few questions.
>

This would be greatly appreciated. :)

> Before I ask any questions that have already been answered, is there a way I
> can read past questions to the mailing list?
>

Here's a link to the list archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=cpp-netlib-devel

HTH

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

[cpp-netlib-devel] hello

[Tim W. <tim...@gm...>]

Hello,

I'm interested in finding out if there is any value I can add to this
effort.  For now I'll just hang out for a bit and watch what is going on.
And throw in a few questions.

Before I ask any questions that have already been answered, is there a way I
can read past questions to the mailing list?

Thanks,
Tim

[cpp-netlib-devel] Building and Testing Against Boost "tunk"

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

Hi again everyone!

With the most recent Boost move from CVS to subversion, I've taken the
liberty of making sure that the library currently works with the
version in "trunk" -- which is the development tree of the Boost C++
Library. Building/developing against trunk is something I think we
should all be doing to make sure that the code we write will work with
the latest development version of Boost.

After checking out the Boost development tree, I've been able to
successfully run the unit tests without a hitch. Further changes to
the code will assume that the libraries in Boost trunk are present in
the build environment.

Please let me know if you run into problems. Thanks and have a great
day everyone!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] New Project/Release Manager and Project Admin

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

Mike,

On 29/08/2007, Michael Dickey <mi...@mi...> wrote:
>
> Hello, Dean.  Please add me on as a developer.  My sourceforge username
> is "mikedickey"


Done, thanks.
Glyn

Re: [cpp-netlib-devel] New Project/Release Manager and Project Admin

[Michael D. <mi...@mi...>]

Hello, Dean.  Please add me on as a developer.  My sourceforge username 
is "mikedickey"

Thanks,
-Mike

Dean Michael Berris wrote:
> Hi Everyone,
>
> I'd just like to announce that after an overdue announcement, Glyn
> Matthews is now the Project Manager and Project Admin for the C++
> Networking Library project. The administrative powers of the project
> are now shared between me and him -- so if you want to be added as a
> developer to the Sourceforge project please contact either me or Glyn
> Matthews directly.
>
> Please note that I will try and complete most of the implementation
> requirements to lay the groundwork for other components to be built on
> top of the current Message implementation. Please file feature
> requests/bugs to the appropriate sourceforge tracker(s).
>
> I'm currently working on more stuff to be added (especially in the
> transformation layer) mainly iterator adapters, and what not.
>
> I'll also start implementing a message type with wide character support.
>
> When time permits, I should start writing the simple HTTP 1.0 client
> implementation based on the message class.
>
> If you would like to pick up from where the code is currently at,
> please feel free to do so. Let me know if you need anything to get
> started. Let's get the dialog going so that we can be able to
> accomplish more as we go along.
>
> PS. If you already have code implemented which you'd like to
> contribute, please feel free to send the files over to me or whoever
> would have the time and bandwidth to try and integrate what we already
> have into the repository.
>
>   

[cpp-netlib-devel] New Project/Release Manager and Project Admin

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

Hi Everyone,

I'd just like to announce that after an overdue announcement, Glyn
Matthews is now the Project Manager and Project Admin for the C++
Networking Library project. The administrative powers of the project
are now shared between me and him -- so if you want to be added as a
developer to the Sourceforge project please contact either me or Glyn
Matthews directly.

Please note that I will try and complete most of the implementation
requirements to lay the groundwork for other components to be built on
top of the current Message implementation. Please file feature
requests/bugs to the appropriate sourceforge tracker(s).

I'm currently working on more stuff to be added (especially in the
transformation layer) mainly iterator adapters, and what not.

I'll also start implementing a message type with wide character support.

When time permits, I should start writing the simple HTTP 1.0 client
implementation based on the message class.

If you would like to pick up from where the code is currently at,
please feel free to do so. Let me know if you need anything to get
started. Let's get the dialog going so that we can be able to
accomplish more as we go along.

PS. If you already have code implemented which you'd like to
contribute, please feel free to send the files over to me or whoever
would have the time and bandwidth to try and integrate what we already
have into the repository.

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Initial requirements

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

Hi Dean,

On 19/08/07, Dean Michael Berris <mik...@gm...> wrote:
>
> On 8/19/07, Glyn Matthews <gly...@gm...> wrote:
>
> Very well written document. I couldn't have come up with anything
> close or better.


Thank you.  Do you have any comments?  It still needs to be fleshed out a
bit more.


I'll try and add more details to the Architecture document in a while.
> I see that you've edited that page as well.


Yeah well I started editing that before realising I was writing specs rather
than architecture, which is why I started writing that.  What I added to the
architecture docs doesn't really come to much.
G

Re: [cpp-netlib-devel] Initial requirements

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

On 8/19/07, Glyn Matthews <gly...@gm...> wrote:
> All,
>
>
> I've added a requirements specification document to the wiki at sourceforge:
> http://cpp-netlib.wiki.sourceforge.net/Software+Requirements+Specification
>
> If you'd like to take a look and make comments, I hope we'll be able to
> flesh out what progress we need to make in the coming weeks and months.
>

Hi Glyn!

Very well written document. I couldn't have come up with anything
close or better.

I'll try and add more details to the Architecture document in a while.
I see that you've edited that page as well.

> Cheers,
> Glyn
>

Thanks again Glyn!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

[cpp-netlib-devel] Initial requirements

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

All,


I've added a requirements specification document to the wiki at sourceforge:
http://cpp-netlib.wiki.sourceforge.net/Software+Requirements+Specification

If you'd like to take a look and make comments, I hope we'll be able to
flesh out what progress we need to make in the coming weeks and months.

Cheers,
Glyn

Re: [cpp-netlib-devel] Project/release manager

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

Hi Peter,

On 31 Jul 2007 23:20:49 +0200, Peter Simons < si...@cr...> wrote:
>
> Hi Glyn,
>
> first of all, thank you for the effort to revive the cpp-netlib
> project. I don't believe that a free software project needs
> leadership, but every non-trivial effort needs coordination because
> it is impossible for everyone to think about everything in great
> detail.

<snip />

I have to say I'm in complete agreement with everything you said in your
e-mail.  I'm happy that it looks like there are others here who share the
same perspective on this project


It's only natural, but it is a problem, because we should not be
> thinking about our code or code we already have, we should ask
> ourselves: what do the users want? What does an everyday C++
> programmer want to do with the Internet, but can't, because it is
> too difficult? What kind of functionality would he or she love to
> find in our library?


These are indeed the relevant questions we should be asking ourselves.


I feel the best approach to jump-starting this mailing list is to
> work out a readable document that describes our goal.

Yep, and that'll be the first thing that I'll be prodding Dean to continue
to do on the wiki, since he already has some clear ideas as to what he
wants.  From there we can discuss what to do, bringing in other people to
find out what they might want from our library and begin to make some
progress.


A collection
> of random classes just doesn't do it. You seem to have a high-level
> perspective on all those problems, Glyn. I feel that qualifies you
> very much for the task of coordinating this effort. Us in-depth
> experts all too frequently find it hard to let go of all the detail
> and look at the big picture. Someone has to, or this project won't
> go anywhere.


Thanks for the confidence, its good to know we're on the same course.
Regards,
Glyn

Re: [cpp-netlib-devel] Project/release manager

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

Hi Glyn!

On 7/31/07, Glyn Matthews <gly...@gm...> wrote:
<snipped very insightful message>
>
> The first thing to do is to finish the architecture document on the wiki and
> some initial specs, so that we can begin to proceed.
>

I agree. Thanks Glyn for stepping up and taking this spot! It's been
apparent that I haven't been able to keep the momentum going with all
that's been happening in real life lately... That being said I look
forward to writing more code towards a release soon -- or helping
integrate already existing code into the project.

> I'm looking forward to (continuing) working with you,
> Glyn
>

Same here. Thanks again Glyn!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Project/release manager

[Peter S. <si...@cr...>]

Hi Glyn,

first of all, thank you for the effort to revive the cpp-netlib
project. I don't believe that a free software project needs
leadership, but every non-trivial effort needs coordination because
it is impossible for everyone to think about everything in great
detail.

Many contributors to this list are extremely knowledgeable and have
already written significant amounts of code. A problem is that we,
the people who spent weeks and months of our spare time to write
that code, have a tendency to think "I need my code polished and
tested so that it can become part of Boost". This perceived honor is
our egoistical motivation for participating in an altruistic effort
-- a free software project.

It's only natural, but it is a problem, because we should not be
thinking about our code or code we already have, we should ask
ourselves: what do the users want? What does an everyday C++
programmer want to do with the Internet, but can't, because it is
too difficult? What kind of functionality would he or she love to
find in our library?

The ability to perform an HTTP request with a handful of function
calls is obviously appealing. The ability to parse the message text
into RFC-compliant data structures is a part of that task -- so are
the pretty-printers to format the data structures into message text.
It should be possible to performed any number of simultaneous
requests asynchronously. Some notion on keep-alive support is
required, and a connection cache might even take advantage of that
transparently.

To offer this kind of functionality would be quite a challenge. To
get there, we need to agree on the user API. Once we know what the
user's program will look like when he uses our code, we can divide
this huge problem into a number of fairly small problems, assign a
volunteer to each of those sub-tasks, and start hacking away.

I feel the best approach to jump-starting this mailing list is to
work out a readable document that describes our goal. A collection
of random classes just doesn't do it. You seem to have a high-level
perspective on all those problems, Glyn. I feel that qualifies you
very much for the task of coordinating this effort. Us in-depth
experts all too frequently find it hard to let go of all the detail
and look at the big picture. Someone has to, or this project won't
go anywhere.

Anyway, that's my perspective. Thank you for sharing yours.

Best regards,
Peter

[cpp-netlib-devel] Project/release manager

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

Dear all,


In the interests of getting some momentum going with this project and given
the fact that this list has seen a number of people state they're already
willing to donate time and code, I have decided I am willing to donate some
time to becoming a project / release manager.  What especially interests me
about this project is the obvious interest for network support in C++, the
potentially large developer base and the fact that I can learn a lot more
about this kind of project development.

I feel that the main challenge is that, since there are already a few people
with code ready to contribute, its necessary to co-ordinate everybody's
efforts rather than to innovate.  Dean has made an excellent start with the
message template and it shouldn't take very long to have something workable
rather soon.

If there's anything you feel you need to discuss, please bring it up here or
I'm available by private e-mail.

The first thing to do is to finish the architecture document on the wiki and
some initial specs, so that we can begin to proceed.

I'm looking forward to (continuing) working with you,
Glyn

[cpp-netlib-devel] libpion

[Michael D. <mi...@at...>]

Hi everyone,

I came across this project via the asio mailing list.  I've written a  
library called "libpion" which is "a c++ development library for  
implementing lightweight HTTP interfaces."  It supports server-side  
HTTP 1.0/1.1 + HTTPS using a plug-in framework to associate uris with  
object code.   I'd be happy to help merge this code into cpp-netlib.

http://www.atomiclabs.com/libpion

Take care,
-Mike

Re: [cpp-netlib-devel] Dependence on std::string

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

Q2hlbmcsIERlYW4sCgpPbiAxOC8wNy8wNywgRGVhbiBNaWNoYWVsIEJlcnJpcyA8bWlraGFpbGJl
cmlzQGdtYWlsLmNvbT4gd3JvdGU6Cj4KPiBIaSBDaGVuZyEKPgo+IE9uIDcvMTgvMDcsIMGss8cg
PHJoeXRobS5tYWlsQGdtYWlsLmNvbT4gd3JvdGU6Cj4gPiBIaSwgR2x5bgo+ID4KPgo+IFRoYW5r
cyB2ZXJ5IG11Y2ggQ2hlbmcgZm9yIHBvc3RpbmcgdGhlIGFib3ZlIGV4cGxhbmF0aW9uIQo+Cj4g
U28gR2x5biwgd291bGQgeW91IHRoaW5rIHRoZSBhYm92ZSBpbnNpZ2h0cy9zdWdnZXN0aW9ucyBo
ZWxwPwoKCgpZZXMsIHRoYXQncyBjbGFyaWZpZWQgdGhpbmdzIGZvciBtZS4gIEkgaGF2ZSB0byBi
ZSBob25lc3QgYW5kIHNheSBJIGRpZG4ndApyZWFsaXNlIHRoYXQgdGhlIHRhZ3Mgd291bGQgYWxz
byBzcGVjaWFsaXplIGhvdyB0aGUgc3RyaW5nIHdvdWxkIGJlCnN0b3JlZC4gICBCdXQgSSBzZWUg
bm93IHRoZSBiZW5lZml0cyBvZiB0aGlzIGFwcHJvYWNoLgoKU28gaXRzIG5vdCBub3cgd29ydGgg
bG9va2luZyBhdCB0aGUgY29kZSBJIGRldmVsb3BlZCAodW5sZXNzIHlvdSB0aGluayB5b3UKZ2Fy
bmVyIHNvbWV0aGluZyBlbHNlIG91dCBvZiBpdCksIGJ1dCBhdCBsZWFzdCBpdCBsZWQgbWUgdG8g
bGVhcm4gc29tZXRoaW5nCm5ldyA7KQpHbHluCg==

Re: [cpp-netlib-devel] Why header only? (was Re: Dependence on std::string)

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

Hi Matt!

On 7/18/07, Matt Gruenke <mgr...@in...> wrote:
> Dean Michael Berris wrote:
>
> >
> >* Only pay for what you use -- with how templates work in C++, only
> >the things that are actually used will be made part of the binary
> >output. That means, even if you have a class that has an inordinate
> >number of member methods, only those methods you actually use will be
> >compiled to the final output binary. That's space efficiency without
> >having to rely on the compiler's non-standard optimizations (like dead
> >code removal, etc. if you didn't use templates).
> >
> >
>
> All linkers I'm aware of pull in only those symbols that are needed.
>

Yes, but remember you need to build the shared/static library first --
which takes up space -- then link to the library next.

>
> >* Cross-platform functionality without the baggage -- with the target
> >of being usable on all platforms on which the Boost C++ library can be
> >used in, the idea now is to not require applications that need to use
> >the network library to link externally to a shared library. This
> >allows the users to actually get the functionality they need into the
> >application -- and since we're not implementing system-level
> >implementations of the network protocols, making your applications
> >require a shared library would be just "not courteous". Again, the
> >point here is that we can allow people to leverage on client/server(?)
> >source-level implementations without having them link to an external
> >library.
> >
> >
>
> I thought the Boost version of ASIO was no longer header-only.

It still is. It does depend though on Boost.System which is built on a
per-platform basis as an external library.

> If
> that's true, then you still have a link dependency.  Even if it weren't,
> wouldn't you still have link dependencies on system libraries, on some
> platforms?  Having a non-header-only library allows you to abstract upon
> which underlying libraries yours depends, which could actually simplify
> life for users.
>

The only requirement which I hope the networking library will ever
need would be Boost (because it's intended to be developed for
inclusion into Boost) and the standard C++ library of your platform.
In the case on Windows using MSVC, if you needed to build
network-aware applications you'd need the platform SDK for the
platform you want to develop on anyway. I don't see how much simpler
an externally built library would make life easier for users of the
library (which I presume are developers) if they needed to build an
extra library and ship it along with their software too when they can
have it all in the software built-in.

>
> >* Version Freeze and Backward Compatibility -- as an offshoot of the
> >above, when we put out changes we just need to worry about people who
> >will be using the new version of the library in their projects "to
> >build" and not have to worry about applications that link to the
> >library externally and breaking API's in that manner. I envision the
> >library to be useful for enabling applications to invoke remote
> >network resources using a simple set of functions and objects in a
> >very efficient manner -- adding an external library to be required to
> >run the application is _not_ included in the "simple set of functions
> >and objects in a very efficient manner".
> >
> >
>
> Shared libraries provide the opportunity to fix application bugs that
> reside in dependent libraries, by using a patched version of said
> libraries.  If you don't value that capability, then you can use static
> libraries.
>

Shared libraries are only useful if you have multiple applications
using the same library during runtime. Fixing application bugs is not
the domain of the library -- though fixing library bugs is the domain
of the library.

Case in point: ACE. If my application was coded poorly and works with
ACE, is it ACE's responsibility to fix the application bugs I've
introduced? Now if the bug was something that ACE introduced, then
it's something that the authors/developers of ACE would have to deal
with. If there was a change in the ACE API, you'd then have to rebuild
the application anyway -- in which case you just lost the advantage
you just pointed out, where you can "pull the rug under the
application" without making too much of a fuss.

The main point of providing a header-only library is to "build-in" the
functionality that you need into the application. The external
dependency solution is never attractive especially when you can always
build stuff into the solution you're building.

OTOH, if we were talking about a widget toolkit library (like Qt or
MFC or .NET) then I would agree with you completely. But in the case
of providing a simple Boost.Asio based efficient, extensible, simple,
and comprehensive networking library I don't agree that an external
library would be an advantage over a header-only library especially in
the above regard.

>
> >So as much as possible, we avoid dynamic polymorphic types because it
> >requires Runtime Type Information (RTTI) which tends to slow down
> >code.
> >
>
> I didn't say anything about dynamic polymorphic types.  I don't know if
> you're referring to the string issue, but I wasn't advocating a specific
> solution to that problem.
>

I was making a point as to why I wouldn't want to have both RTTI and
external linking together. The reality of the situation is (and as how
I understand it), if you need any sort of runtime type information
checking, and when you have runtime-value-dependent implementations --
like in the program_options, serialization, regular expression, etc.
libraries -- then the only way you can achieve it is through the use
of an externally linked library with RTTI code. Otherwise, there's no
point in having your code compiled as a separate unit when it can stay
header-only (example: Spirit).

>
> >If there's one compelling reason why we should build external
> >libraries (which I honestly think there isn't) I would love to hear
> >it.
> >
>
> Reduced compile times.  Potentially simplified link dependencies.
> Avoiding inclusion of system & other library header files, which often
> have side-effects.
>

Reduced compile times is not a plus in my book, sorry.

Link dependencies? If the library was header-only, I don't see why
there would be link dependency issues.

I don't see as well how inclusion of system libraries would have a
negative side effect... I also do not see how you can make your C++
application work on the platform you want it to work on if you didn't
use the system libraries of that platform...

> In general, I mostly agreed with the decisions Boost has made, in this area.

I agree with the decisions of Boost as well. And while I do agree that
there are some cases where an external library would be necessary, I
don't see this one (the C++ Networking Library) requiring an external
library built. Of course, it could be built that way but I don't see
it being a requirement.

>
> I understand it's a tradeoff.  Thanks for taking the time to articulate
> your position.
>

Thank you for your comments as well. It allows me to think about the
earlier decisions and what my stance on the matter really is.

Have a great day! :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Why header only? (was Re: Dependence on std::string)

[Matt G. <mgr...@in...>]

Dean Michael Berris wrote:

>On 7/17/07, Matt Gruenke <email address removed by me> wrote:
>  
>
>>why would it be a requirement
>>for something as big as a network protocol library to be header-only?
>>    
>>

>Okay, let me try to answer why it should be header only:
>
>* Only pay for what you use -- with how templates work in C++, only
>the things that are actually used will be made part of the binary
>output. That means, even if you have a class that has an inordinate
>number of member methods, only those methods you actually use will be
>compiled to the final output binary. That's space efficiency without
>having to rely on the compiler's non-standard optimizations (like dead
>code removal, etc. if you didn't use templates).
>  
>

All linkers I'm aware of pull in only those symbols that are needed.


>* Cross-platform functionality without the baggage -- with the target
>of being usable on all platforms on which the Boost C++ library can be
>used in, the idea now is to not require applications that need to use
>the network library to link externally to a shared library. This
>allows the users to actually get the functionality they need into the
>application -- and since we're not implementing system-level
>implementations of the network protocols, making your applications
>require a shared library would be just "not courteous". Again, the
>point here is that we can allow people to leverage on client/server(?)
>source-level implementations without having them link to an external
>library.
>  
>

I thought the Boost version of ASIO was no longer header-only.  If 
that's true, then you still have a link dependency.  Even if it weren't, 
wouldn't you still have link dependencies on system libraries, on some 
platforms?  Having a non-header-only library allows you to abstract upon 
which underlying libraries yours depends, which could actually simplify 
life for users.


>* Version Freeze and Backward Compatibility -- as an offshoot of the
>above, when we put out changes we just need to worry about people who
>will be using the new version of the library in their projects "to
>build" and not have to worry about applications that link to the
>library externally and breaking API's in that manner. I envision the
>library to be useful for enabling applications to invoke remote
>network resources using a simple set of functions and objects in a
>very efficient manner -- adding an external library to be required to
>run the application is _not_ included in the "simple set of functions
>and objects in a very efficient manner".
>  
>

Shared libraries provide the opportunity to fix application bugs that 
reside in dependent libraries, by using a patched version of said 
libraries.  If you don't value that capability, then you can use static 
libraries.


>So as much as possible, we avoid dynamic polymorphic types because it
>requires Runtime Type Information (RTTI) which tends to slow down
>code.
>

I didn't say anything about dynamic polymorphic types.  I don't know if 
you're referring to the string issue, but I wasn't advocating a specific 
solution to that problem.


>If there's one compelling reason why we should build external
>libraries (which I honestly think there isn't) I would love to hear
>it.
>

Reduced compile times.  Potentially simplified link dependencies.  
Avoiding inclusion of system & other library header files, which often 
have side-effects.

In general, I mostly agreed with the decisions Boost has made, in this area.


>I hope this makes sense. :-)
>  
>

I understand it's a tradeoff.  Thanks for taking the time to articulate 
your position.


Matt

Re: [cpp-netlib-devel] Dependence on std::string

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

SGkgQ2hlbmchCgpPbiA3LzE4LzA3LCDBrLPHIDxyaHl0aG0ubWFpbEBnbWFpbC5jb20+IHdyb3Rl
Ogo+IEhpLCBHbHluCj4KPiBJIGFtIHJlY2VudGx5IHdvcmtpbmcgb24gYSBiaW5hcnkgcHJvdG9j
b2wgb3JpZW50ZWQgbmV0d29yayBmcmFtZXdvcmsKPiBiYXNlZCBvbiBBU0lPIGluIG15IHByb2pl
Y3QuIFNvIEkgZG8gY2FyZSBtb3JlIGFib3V0IGEgYmluYXJ5IHByb3RvY29sCj4gb3JpZW50ZWQg
bWVzc2FnZSB0eXBlLiBzbyBJIGhhdmUgb25jZSBhc2tlZCBEZWFuIGEgcXVlc3Rpb24gZHVyaW5n
IGEKPiBwcml2YXRlIGNvbW11bmljYXRpb246Cj4KPiAgICAgV2hhdCdzIHRoZSBncmFudWxhcml0
eSBvZiB0aGUgVGFnIHRlbXBsYXRlIHBhcmFtZXRlciBvZgo+ICAgICBiYXNpY19tZXNzYWdlPD4g
dGVtcGxhdGU/IE9uZSB0YWcgcGVyIG1lc3NhZ2UgdHlwZSAoSSBtZWFucwo+ICAgICB0ZXh0L2Jp
bmFyeSBoZXJlKSBvciBvbmUgdGFnIHBlciBwcm90b2NvbD8KPgo+IEFuZCBEZWFuIHJlcGxpZWQ6
Cj4KPiAgICAgVGhlIFRhZyB0ZW1wbGF0ZSBwYXJhbWV0ZXIgaXMgbWVhbnQgdG8gZGlmZmVyZW50
aWF0ZSB0aGUgbWVzc2FnZQo+ICAgICB0eXBlcyAtLSBmb3IgZWFzeSBleHRlbnNpb24uIFRoYXQg
bWVhbnMsIHRvIGJlIGNsZWFyLCB0aGUgbWVzc2FnZQo+ICAgICB0YWdzIEkgZW52aXNpb24gYXJl
Ogo+Cj4gICAgIHRhZ3M6OnVuaWNvZGUKPiAgICAgdGFnczo6dGV4dCAodGFnczo6ZGVmYXVsdF8p
Cj4gICAgIHRhZ3M6OmJpbmFyeQo+ICAgICB0YWdzOjpzdHJlYW0KPiAgICAgdGFnczo6c2VyaWFs
aXphYmxlX3RleHQKPiAgICAgdGFnczo6c2VyaWFsaXphYmxlX2JpbmFyeQo+ICAgICB0YWdzOjpz
ZXJpYWxpemFibGVfeG1sCj4KPiAgICAgQW1vbmcgbWFueSBvdGhlcnMgSSBoYXZlbid0IHRob3Vn
aHQgb2YgeWV0LiA6RAo+Cj4gICAgIFRoZXkgYXJlIHRhZ3MsIGJlY2F1c2UgSSBkb24ndCBpbnRl
bmQgdG8gcHV0IHRoZSBvdmVyaGVhZCBvZiBhbgo+ICAgICBhYnN0cmFjdCBtZXNzYWdlIGNsYXNz
IGFzIHRoZSBiYXNlIGNsYXNzIGZvciBhbGwgdGhlIG1lc3NhZ2UKPiAgICAgdHlwZXMuICBUaGF0
IGFsbG93cyB1cyB0byBpbXBsZW1lbnQgYSBiYXNpY19tZXNzYWdlPHRhZ3M6OnRleHQ+Cj4gICAg
IGFuZCBiYXNpY19tZXNzYWdlPHRhZ3M6OmJpbmFyeT4sIGFuZCBzcGVjaWFsaXplIHRoZQo+ICAg
ICBpbXBsZW1lbnRhdGlvbnMgd2l0aG91dCBoYXZpbmcgdG8gcmVseSBvbiBpbmhlcml0YW5jZSBh
bmQgcnVudGltZQo+ICAgICBwb2x5bW9ycGhpc20uCj4KPiBBcyBEZWFuIHN0YXRlZCwgd2l0aCBz
dWNoIHRhZ3MsIHdlIGNhbiBzcGVjaWFsaXplIGRpZmZlcmVudCBtZXNzYWdlCj4gdHlwZXMuIEFu
ZCBJIHRoaW5rIHRoZSBtZXNzYWdlIHR5cGUgdGFncyBzaG91bGQgaW1wbHkgdGhlIHVuZGVybHlp
bmcKPiBzdG9yYWdlIHBvbGljeSBvZiB0aGF0IHR5cGUgb2YgYmFzaWNfbWVzc2FnZS4gU2F5LCB0
YWdzOjp0ZXh0Cj4gKHRhZ3M6OmRlZmF1bHRfKSBpbXBsaWVzIGFuIHN0ZDo6c3RyaW5nIHN0b3Jh
Z2UgZmFjaWxpdHksIHdoaWxlCj4gdGFnczo6dW5pY29kZSBpbXBsaWVzIGFuIHN0ZDo6d3N0cmlu
ZyBzdG9yYWdlIGZhY2lsaXR5LCBhbmQKPiB0YWdzOjpzdHJlYW0gbWF5IGltcGxpZXMgYSBib29z
dDo6YXNpbzo6c3RyZWFtYnVmIHN0b3JhZ2UgZmFjaWxpdHkgKGFzCj4gd2hhdCBJJ3ZlIGRvbmUg
aW4gbXkgb3duIHByb2plY3QpLiBTbyBJIHN1Z2dlc3Qgd2UgY291bGQgaW5jbHVkZSBhCj4gc3Rv
cmFnZV90eXBlIGluIHRoZSB0YWdzIHN0cnVjdDoKPgo+ICAgICBzdHJ1Y3QgdGFncyB7Cj4gICAg
ICAgICBzdHJ1Y3QgZGVmYXVsdF8gewo+ICAgICAgICAgICAgIHR5cGVkZWYgc3RkOjpzdHJpbmcg
c3RvcmFnZV90eXBlOwo+ICAgICAgICAgfTsKPgo+ICAgICAgICAgdHlwZWRlZiBkZWZhdWx0Xzo6
dGV4dDsKPgo+ICAgICAgICAgc3RydWN0IHVuaWNvZGUgewo+ICAgICAgICAgICAgIHR5cGVkZWYg
c3RkOjp3c3RyaW5nIHN0b3JhZ2VfdHlwZTsKPiAgICAgICAgIH07Cj4KPiAgICAgICAgIHN0cnVj
dCBzdHJlYW0gewo+ICAgICAgICAgICAgIHR5cGVkZWYgYm9vc3Q6OmFzaW86OnN0cmVhbWJ1ZiBz
dG9yYWdlX3R5cGU7Cj4gICAgICAgICB9Owo+Cj4gICAgICAgICAuLi4KPiAgICAgfTsKPgo+ICAg
ICB0eXBlZGVmIGJhc2ljX21lc3NhZ2U8dGFnczo6dGV4dD4gbWVzc2FnZTsKPiAgICAgdHlwZWRl
ZiBiYXNpY19tZXNzYWdlPHRhZ3M6OnVuaWNvZGU+IHdtZXNzYWdlOwo+ICAgICB0eXBlZGVmIGJh
c2ljX21lc3NhZ2U8dGFnczo6c3RyZWFtPiBzbWVzc2FnZTsKPiAgICAgLi4uCj4KPiBXb3VsZCB0
aGlzIGJlIHNhbmU/Cj4KCllvdSB0b29rIHRoZSB3b3JkcyBvdXQgb2YgbXkgZW1haWwuIDopCgpF
c3NlbnRpYWxseSwgeW91IGhhdmUgcHJldHR5IG11Y2ggZXhwbGFpbmVkIHdoYXQgSSBoYXZlIGJl
ZW4gdGhpbmtpbmcKb2YgZG9pbmcgYWxsIHRoaXMgd2hpbGUuIFRoZSAndGFnJyBpcyBtZWFudCB0
byBkaWZmZXJlbnRpYXRlIGJldHdlZW4KaW1wbGVtZW50YXRpb25zIG9mIHRoZSBtZXNzYWdlIHR5
cGUsIGFuZCB0aHVzIHRoZSBiZWhhdmlvciBvZiB0aGUKYWxnb3JpdGhtcyB0aGF0IG9wZXJhdGUg
b24gdGhlc2UgbWVzc2FnZSB0eXBlcy4gU28gc2luY2Ugd2UgaGF2ZSAob3IKc2hvdWxkIGhhdmUp
IHRoZSBUYWcgdGVtcGxhdGUgcGFyYW1ldGVyIGluIGFsbCB0aGUgaW1wbGVtZW50YXRpb25zIG9m
CnRoZSBhbGdvcml0aG1zLCB3ZSBzaG91bGQgYmUgYWJsZSB0byByZWZhY3RvciB0aGVtIGFwcHJv
cHJpYXRlbHkgdG8KbWFrZSB0aGVtIGVpdGhlcgoKICAxKSB3b3JrIGRpZmZlcmVudGx5IGZvciBk
aWZmZXJlbnQgbWVzc2FnZSB0eXBlcwogIDIpIG5vdCBiZSBhdmFpbGFibGUgZm9yIHNlbGVjdGVk
IG1lc3NhZ2UgdHlwZXMgb3IKICAzKSBiZSBnZW5lcmljIGVub3VnaCB0byB3b3JrIHdpdGggYWxs
IHRoZSBtZXNzYWdlIHR5cGVzCgotLSB0aGlzIHdvdWxkIGFsbG93IHVzIHRvIGdyb3cgdGhlIGxp
YnJhcnkgYXMgbmVjZXNzYXJ5IGluIGRpZmZlcmVudApkaXJlY3Rpb25zIGZvciBiaW5hcnkgaW1w
bGVtZW50YXRpb25zLCB1bmljb2RlIGltcGxlbWVudGF0aW9ucywKc3RhbmRhcmQgc3RyaW5nIGlt
cGxlbWVudGF0aW9ucywgZXRjLgoKUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoYXQncyBub3QgY2xl
YXIgeWV0LiBCYXNpY2FsbHkgdGhvdWdoIENoZW5nJ3MKcXVvdGluZyBteSBtZXNzYWdlIHRvIGhp
bSAod2hpY2ggSSB0aGluayBzaG91bGQgaGF2ZSBiZWVuIENDJ2VkIG9yCnNlbnQgdG8gdGhlIG1h
aWxpbmcgbGlzdCBhcyB3ZWxsLCA7KSApIHByZXR0eSBtdWNoIGV4cGxhaW5zIHdoYXQgSSBoYWQK
aW4gbWluZC4KCj4gQ2hlZXJzCj4gQ2hlbmcKPgoKVGhhbmtzIHZlcnkgbXVjaCBDaGVuZyBmb3Ig
cG9zdGluZyB0aGUgYWJvdmUgZXhwbGFuYXRpb24hCgpTbyBHbHluLCB3b3VsZCB5b3UgdGhpbmsg
dGhlIGFib3ZlIGluc2lnaHRzL3N1Z2dlc3Rpb25zIGhlbHA/CgotLSAKRGVhbiBNaWNoYWVsIEMu
IEJlcnJpcwpodHRwOi8vY3BsdXNwbHVzLXNvdXAuYmxvZ3Nwb3QuY29tLwptaWtoYWlsYmVyaXMg
QVQgZ21haWwgRE9UIGNvbQorNjMgOTI4IDcyOTE0NTkK

Re: [cpp-netlib-devel] Dependence on std::string

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

Hi Glyn!

On 7/17/07, Glyn Matthews <gly...@gm...> wrote:
> Guys,
>
> I've been giving a little thought to something Dean mentioned in his last
> message about using std::string in the network library.
>
> The first thing I thought of was that Dean stated that "everything is a
> template".  Apart of course from std::string.  I have created a branch in
> SVN named gxm) which replaces all references to std::string with an extra
> template parameter.  Happily, this passes all the original tests (with an
> additional template specialization so that const char * is converted to a
> std::string).  However, this creates a problem (certainly with GCC) because
> the wchar_t typedef is the same as char and its not possible to overload
> const wchar_t * in the same way.  So the following code will not compile:
>
> wmessage wmsg;
> wmsg << header(L"wide characters");
>
> Another thing I see is that boost filesystem and boost program_options have
> dealt with a very similar problem to this.  But if we use the same approach
> (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then
> we'd have to accept the use of a cpp source file, meaning we will no longer
> have a header only library.
>
> What do others think about this?
>

I haven't checked out your code yet, but I'm excited to see how this
works (or breaks). :)

Our problem primarily here is that header(L"key", L"value") is an
inline method which returns a specific instance of type
header_directive<tags::default_>. Now if we overloaded that inline
method with say something like:

    inline impl::header_directive<tags::unicode>
    header(typename tags::unicode::str_type const & header_name,
            typename tags::unicode::str_type const & header_value) {
        return impl::header_directive<tags::unicode>(header_name,
                header_value);
    };

And then do a typedef such as:

  typedef basic_message<tags::unicode> message_w ;
  typedef basic_message<tags::unicode> wide_message ;
  typedef basic_message<tags::unicode> message_wide ;

We'd also like to then have tags::unicode typedef the correct type for
the string as 'str_type'. That way we can customize just tags::unicode
for different platforms, and have the check for GCC implement the
correct type there.

Would you think that works? I hope I made sense... :D

(Cheng, I will indulge you with that request from the other email...
Let me write down my thoughts.) :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459