Re: [boost] Re: sockets /network programming Requirements

From: Iain.Hanson_at_[hidden]
Date: 2001-07-31 13:49:49

Author:  williamkempf (williamkempf_at_[hidden]) at unix,mime
Date:    31/07/01 17:54

--- In boost_at_y..., Iain.Hanson_at_u... wrote: 
>>      
>> Author:  williamkempf (williamkempf_at_h...) at 
>unix,mime > Date:    30/07/01 20:19
>> 
[snip]

>>      
>> >* Exceptions should not be used for precondition violations. 
>>>Assertions and/or error returns should be used instead in this 
>> >case.
>> 
>> Why? I would not be inclined to use error returns for precondition 
>> violation. I've not seen much of a discussion of assertion v 
>> exceptions, however, I would be inclined to use assertions for 
>> static preconditions and would prefer to generate a compile time 
>> error. But for dynamic preconditions I owuld use an exception so 
>> that the user can take some recovery action. 
     
>This was discussed thoroughly on this list, so check the archives.  I 
>had problems with this at first as well, but the reasons given in the 
>discussion make sense.  Exceptions should be reserved for errors that 
>are out of the programmers control (such as attempting to read on a 
>socket that's been disconnected by the remote host).

Thanks for the pointer. I took a look and I have no problems with it. 
In fact, I agree with it.

[snip]
     
>Ports are an integral type, yes, but programmers often create port 
>ids by "friendly name" via getservbyname(), just as one example of 
>why there should be a port type as well.

Good point. Thanks.
     
>> >* I don't think FTP, HTTP or other protocol client/server classes 
>> >should even be considered for inclusion, at least in a first 
>> >submission.
>> 
>> I think these, and other applications level protocols would make a 
>> useful addition to boost. They would need to be built ontop of the 
>> other layer(s) and I don't plan to look to closely at them any time 
>> in the near future. Except perhaps as examples of applications that 
>> should be *relatively* easy to implemnt with this library.
     
>Yes, but each protocol is a library in and of itself.  I'm not saying they 
>shouldn't be submitted to Boost, I'm saying they should not be a part of 
>Boost.Sockets (though they should be implemented in terms of Boost.Sockets).  
>Even if you and/or others think they should be part of Boost.Sockets directly, 
>they should not be included in any initial submission.  Each of these protocols
>is going to be complex to get the interface correct and will drastically effect
>the time frame in which Boost.Sockets can be implemented and submitted, and may
>cause the entire library to be rejected if the review process finds the 
>design/implementation to be poor.  We shouldn't do anything keep the basic 
>socket functionality from being accepted into Boost as soon as possible, since 
>it will be directly usable and beneficial with out the applications level 
>protocols.

I'm not sure about organizing them each into a seperate library. However, on 
reflection, I agree that they do not belong in this library.

/ikh

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.