From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2003-11-10 11:49:06
> 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
> 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
> 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
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk