Boost logo

Boost :

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.


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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at