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
> >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
> 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).
> >* 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
> >two seperate object types, InetAddress and InetPort (pick your
> >for these) that can be constructed with the various options such
> >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
> port type. A port is a Transport Selector and is usually an
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk