#2998: Expose the internals of the network library to make it more extensible
-----------------------------+----------------------------------------------
Reporter: tibbe | Owner:
Type: proposal | Status: new
Priority: normal | Component: libraries/base
Version: 6.10.1 | Severity: normal
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-----------------------------+----------------------------------------------
When creating new libraries on top of the network library it would be
convenient if the library exposed some functions that hide platform
variations so that the new libraries can be written in a portable manner.
Take for example the currently un-exported `pokeSockAddr` function which
marshalls a `SockAddr` into a `sockaddr` struct. This function would be
useful when e.g. writing a binding for the `sendmsg` system call. However,
it's not exported so libraries are forced to define their own version.
This is unfortunate. I propose we add a new module,
`Network.Socket.Internal`, to the network library, that exposes these
portable marshalling functions. It might also be a good idea to expose
some internal data representations in the same way bytestring currently
does. People who write code that uses this internal do so knowing that
there is a risk that the interface and data representations might change.
I've written a patch that exposes some of the library's internal
functions. There are still some documentation to write and perhaps a few
more functions to expose but I think we should reach consensus on whether
this is a good idea to begin with before continuing.
Since this change isn't disruptive I propose a two week consideration
deadline.
Cabal package:
http://johantibell.com/network-2.2.1.tar.gz
Haddock:
http://johantibell.com/network/doc/html/network/
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2998>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
