[boost] Re: Re: Sockets - what's the latest?

[Michel André]

 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



___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: Sockets - what's the latest?

[Michel Andr]

 At the very end of it, network programmers should be using a
 callback-driven interface and not have to worry about multiplexing at
 all, but I agree that for now a third layer should be deferred until
 the basic groundwork has been laid out.

Yes the level 2 interface should be callback driven. And to some agree i
guess the end user have to worry about multiplexeing. At least by declaring
somekind of multiplexor (proactor, reactor) and driving the main
multiplexing loop and letting the user of the library handle threading
issues (apart from the library declaring that the multiplexing primitives
are thread safe).

 I believe we agree :-)  BTW, I've been thinking for awhile that either
 boost::function or boost::signal will provide us with core of that
 callback framework that diverges from the traditional OO approach
 taken by ACE and as is proposed currently on the Wiki.

The asynch part in the sandbox uses boost.function as a completion callback
mechanism. And i the reactor i envision would use boost.function to notify
that a socket is ready.

/Michel

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost