Potential Network SIG

[Sterling Clover]

Simon Marlow-7 wrote:
> 
> Could you elaborate a bit more on "Handles feel to me to be too tricky 
> to reliably map onto"?  I'd like to understand what problems there are, 
> and see if there's some way to address them.
> 

I'm not a network/sockets expert by any means, but I've had to deal with
doing some fiddly stuff in Haskell, and ended up just not trusting the
Handle model, even though I know there's been some improvement and quite a
few bugs have been fixed, etc. Additionally, these comments are based on
what exists now in GHC 6.10.

That said, my first gripe is that lots of operations on Handles are really
only sane for actual files. Maybe these could be abstracted out, by
parameterizing Handles over a phantom type, or by typeclassing? The file
size operations are obviously meaningless, as are the get/set posn
functions, and seeks, but hIsEOF and hLookAhead also seem problematic, not
least because they force a buffer for even ostensibly unbuffered handles.
Additionally, at least on windows, sometimes there is an IOError
OtherException with error text "failed (No Error)" when an EOF should be
provided. [That's really more a behavioural quirk/bug than a failing of
Handles as such, I suppose]

As far as buffering goes, Handles currently couple buffering modes, which is
potentially frustrating if one wants, e.g., no buffering on recv, but block
buffering on send. 

Additionally, for many, though not all applications, it makes sense to
separate the ability to close a handle from the ability to read or write to
it, particularly for high-level, e.g., server APIs.

On the other hand, I'm less concerned with the ability to set options, since
it seems to be that socket options can almost invariably be set as part of
the initial connection/setup phase, and once you have a Handle or whatever,
then the ability to change them isn't really necessary.

Cheers,
Sterl.
-- 
View this message in context: http://www.nabble.com/Potential-Network-SIG-tp25090622p25151428.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.