Proposal #2998: Expose the internals of the network library to make it more extensible
Hi all, In short, I propose that we export some of the internals of the network library in a new module to make it easier to write portable libraries on top of the library. I've added the full proposal, copied from Trac, below. The motivating example is network-bytestring which needs to marshall different socket related data types to support e.g. `sendmsg`. http://hackage.haskell.org/trac/ghc/ticket/2998 Discussion deadline: 2 weeks (non disruptive change) --- 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/ --- Cheers, Johan
Let's do it. The FFI layer should in general be exposed imo, via some .Internals module. -- Don johan.tibell:
Hi all,
In short, I propose that we export some of the internals of the network library in a new module to make it easier to write portable libraries on top of the library. I've added the full proposal, copied from Trac, below. The motivating example is network-bytestring which needs to marshall different socket related data types to support e.g. `sendmsg`.
http://hackage.haskell.org/trac/ghc/ticket/2998
Discussion deadline: 2 weeks (non disruptive change)
---
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/
---
Cheers,
Johan _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
One week remaining until discussion deadline.
Cheers,
Johan
On Mon, Feb 2, 2009 at 12:19 AM, Johan Tibell
Hi all,
In short, I propose that we export some of the internals of the network library in a new module to make it easier to write portable libraries on top of the library. I've added the full proposal, copied from Trac, below. The motivating example is network-bytestring which needs to marshall different socket related data types to support e.g. `sendmsg`.
http://hackage.haskell.org/trac/ghc/ticket/2998
Discussion deadline: 2 weeks (non disruptive change)
---
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:
participants (2)
-
Don Stewart -
Johan Tibell