----- Original Message ----- From: "Caleb Epstein" <caleb.epstein@gmail.com> To: <boost@lists.boost.org> Sent: Friday, June 10, 2005 11:10 AM Subject: Re: [boost] [Ann] socketstream library 0.7 [snip]
Why should EWOULDBLOCK be treated as an EOF? I really think this is trying to fit a square peg - non-blocking sockets - into a round hole - iostreams.
Proposed Socket Library Layers: http://thread.gmane.org/gmane.comp.lib.boost.devel/122484
This is more about the big picture, stacking more complex interfaces on top of it. I think we should implement iostreams for sockets first, then we can go on to implement the mighty httpwistream that will give you "wchar_t"s, whatever the document encoding was. :-)
I think we should implement C++ sockets first, and then iostreams on top of those.
I know there have been others that have agreed with this approach before. Are any of them following this thread?
Dont know if I'm in that group, but certainly agree. This subject was tackled in a recent thread that I contributed to; I don't imagine that that was the first time or that this is the last. Having also been involved in "high speed, network-centric, message-driven applications for a living" I pale at the thought of dumping the burden of iostreams on my already busy CPUs. But that may be a response originating from or near the spleen. The fact that the programming model underlying iostreams is synchronous seems to be acknowledged and that flaw is (in my opinion) untenable in a network world. By the time all necessary changes are made to iostreams to allow it to operate in an asynchronous world, it would be seriously ugly. But that too is just my opinion as I have never implemented such a thing. Aint about to put my hand up either. I like the two layer proposal, but I wonder at the class of applications that would be achievable within the sync iostream model; it might have a very small population. Cheers.