Boost logo

Boost :

From: Michel André (michel.andre_at_[hidden])
Date: 2003-02-15 11:53:30


> Another thing is I think it is important to get at least one
> non-Sockets-based network API in the mix right at the beginning to
> make
> sure the design is truly flexible. I recommend Apple's OpenTransport,
> not because it will be around much longer, but because it is quite a
> bit different from Sockets, and in order to support it we will have to
> think outside of the Sockets domain. Particularly with issues like
> multiplexing, this would put into perspective just what needs to be
> done, rather than assuming we should just provide an analog for
> select() and be done with it.

How would you describe the differences between Apples OpenTransport and
sockets with respects to especially api, options and multiplexings. I think
the design proposed on wiki is rather socket centric the upside would be to
be able to make an library in wich you could use a larger part of the common
interface available with sockets the downside that other api:s would have to
be forced into a socket centric one. Could you help out with an early
OpenTransport port or at least an early review to evaluate the design with
respect to this demand?

What do you others have for view on this, isn't the problem domain hard
enough with the differences in sockets implementations and multiplexing
mechanism on different platforms or should we aim even higher and be able to
incorporate other more "exotic" network apis which cannot easily be mapped
to sockets?

/Michel


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk