Re: [boost] Re: Re: Network library: What we have until now
On Wed, 2005-04-13 at 12:54 +0300, Boris wrote:
Douglas Gregor wrote: [snip]
That's why I started this thread yesterday to ask if we have now a few things everyone agrees with and we can move on.
Boris, there are lots of things in this thread that I disagree with. However, I don't have either the time or the energy to explain them all and work on my own Library in which I have already invested 3 years work. [snip] I
I wish there was a network library already. But the reason why people started with a socket library and then left again unfinished is that there are lots of different opinions about what this library should do and look like.
Some of us have not left but are working quietly in the background. predominately because we have seen the same kinds of discussions happen over and over. The main reason we do not have a socket lib is that even to produce a basic lib supporting blocking, non-blocking and signal driven is that it is a very big undertaking to produce good type safety, and be able to cope with the richness of the BSD socket API functionality. /ikh
Iain Hanson wrote:
On Wed, 2005-04-13 at 12:54 +0300, Boris wrote: [...]
I wish there was a network library already. But the reason why people started with a socket library and then left again unfinished is that there are lots of different opinions about what this library should do and look like.
Some of us have not left but are working quietly in the background. predominately because we have seen the same kinds of discussions happen over and over.
We have already dozens of C++ network libraries - just see the reference list in the Wiki. And the problem with all these network libraries is that everyone here in the list actually would have to read the source code of each and every library to understand the design and evaluate if the design meets his requirements. Instead of forcing everyone of us to go through endless source code it is much easier and takes less time to talk about requirements and possible designs here in the list first and then build a network library based on decisions most of us seem to agree with. This might be slow but so is standardizing. Unfortunately the network topic seems to be a tough one, too, as many interests and goals come together. But I don't see any shortcut if we want a network library which has strong support by many developers. However just as Don I am not hopeless as implementing should be much faster than discussing considering the many experienced network developers on this list. And everyone seems to have a network library at home so we can copy and paste probably a lot of code. ;) Boris
[...]
participants (2)
-
Boris -
Iain Hanson