[boost] Re: Networking library

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2003-11-10 11:49:06

Hi Michel!

> It looks like you have implemented some more things since the last
> discussions and it looks great from my view point. And I really like 
> what I see.

Thanks.  Last time things seemed to fizzle out around the server side
of things.  The wiki still contains a proposal from Boris Schaeling on
the multiplexer design, and I would be interested to here his thoughts,
as well as from the others who commented last time round.

> and  wasn't there an error policy in the sockets library in the sandbox.

Yes, there was, and yes I removed it, or rather moved it into the
socket acceptor, connector and connection classes.  My rationale for
this was essentially
    i) to have a single level in the implementation of the basic socket
       class. The requirement to not include system headers implies a
       non-templated implmentation.  An error policy implies templates,
       so requiring a second level.
   ii) the generation of platform indepenedent error codes was a
       requirement.  This , as in i), implies that an error policy
       needs to be in a level above the basic wrapping.
  iii) I didn't want the complication of converting socket types
       that differed only in there error policies.
   iv) The error policy presumably depends on what use you are making of
       the sockets

> I don't really know how to get the ball rolling on this one. But as I 
> see it
> to get some initial comments we need some kind of documentation besides 
> the
> proof of concept, and we need verification that the asynch stuff can be
> implemented on some other platform (linux maybe)? From the document and
> proof of concept we could get input and maybe get some momentum?

Yes, documentation definitely required.  However, I would be very
interested in just having feedback as to whether mapping all the
underlying demultiplexing variants to a proactor type
user interface is something people are happy with.  Personally, having
a single interface for the user to code to is useful, relegating
blocking/non-blocking/asynch and select/poll/completion-port
choices to be (configurable) implementation details as far the user
is concerned.

Hugo

> I've been busy the last 6 month with a newborn daughter
Congratulations!

> , a 600 km move to new home, starting work in another country
Hope everything went smoothly... (I've been through 4 international
moves so far :-)

> But now I need a C++ project not to get rusty as my daytime work is 
> almost completely .NET and C# :(

How a about a .Net implementation in managed C++ then (joking, I think...).
I haven't seen any discussion here as to whether boost is interested
in running in the managed world, and not having done much yet in .net,
I don't know what is feasable.