Re: sockets /network programming Requirements

From: williamkempf_at_[hidden]
Date: 2001-07-31 11:54:49

--- In boost_at_y..., Iain.Hanson_at_u... wrote:
>      
> Author:  williamkempf (williamkempf_at_h...) at unix,mime
> Date:    30/07/01 20:19
> 
> 
> >I'm interested in this library, and if help is needed I'll lend 
what 
> >ever time I can spare.  My comments on the document:
> 
> Thanks. All help is greatly appreciated.
>      
> >* 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).

> [snip]
>      
> >* One thing I often see done wrong when it comes to "reducing 
> >preconditions" is overloading methods that connect a socket for 
> >numerous ways of specifying the address/port pair.  There should 
be 
> >two seperate object types, InetAddress and InetPort (pick your 
name 
> >for these) that can be constructed with the various options such 
as 
> >URL, IP, friendly name, etc.  The connection routines should only 
> >take these as parameters.  This vastly simplifies much of the user 
> >coding, as well as maintenance required if some new way of 
> >specifying these comes into existence later.
> 
> I had planned to have an address type but I'm not sure that we need 
a 
> port type. A port is a Transport Selector and is usually an 
integral 
> type. I agree that address will be constructable in many differing 
> ways and that a connection would only be creatable with an address.

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.
      
> >* 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.

Bill Kempf