Potential Network SIG
taruti at taruti.net
Sat Aug 22 14:26:02 EDT 2009
Excerpts from Thomas DuBuisson's message of Sat Aug 22 07:49:58 +0300 2009:
> Johan suggested starting a SIG to hammer out a design for a new
> Network API seeing as the current API, a straight-forward Berkeley
> binding, doesn't seem to please anyone in a Haskell context. If you
> want to partake then this e-mail if your heads up. If there is some
> formal method of setting up a Haskell SIG then please let me know.
Sounds good, some notes below.
> 1) Separate low level functions / bindings from high level /
> productive code by placing each in different modules.
> 2) Maintain type safety by using type classes for most things.
> Unlike Network.Fancy and Network.Socket (which have IPv4 and IPv6 as
> constructors of the same data type), I think we should allow for the
> possibility that some users of the library will be limited to just one
> IP version without resorting to partial functions. I suggest type
> classes to cover this aspect (class Address, class Port, etc).
The limitation to one IP-version is a runtime issue not a compile time
one. All the platforms may support either IPv4 or IPv6, both or none
depending on the machine the binary is run on.
I think it should be possible to say "use v4", "use v6" and "use
something" on all target platforms. A typeclass might work fine
if designed correctly.
Also a typeclass makes extensions easier if designed carefully.
> 3) Use Bytestrings (and have corrosponding .Lazy modules) for efficiency.
> As in network-bytestring, any new API should be performance concious
> enough to avoid String.
Ambivalent here. Does it make more sense to have a
send :: StringLike s => ...
sendS :: String -> ...
sendBS :: ByteString -> ...
sendLBS :: L.ByteString -> ...
Also if we have separate functions we need yet another set
of functions when Text is ready.
> 4) Support more features
> Features such as Multicast, Header inclusion (IP_HDRINCL), address
> binding, etc. IOW, most the IP_ and SO_ options of socket (7) and ip
> (7) man pages. It would be rather nice if we were able to expose
> these in a friendly way - but with our cross platform concerns that
> might not be a good idea (e.g. I'm not familiar with windows).
Most of these seem to be for the low level binding?
> 5) Separate IO-less data declarations from IO and any platform
> dependent code in different packages.
Would create lots of nearly identical implementation packages.
Most of the implementation differences across platforms are quite
> 6) Integrate with the rest of hackage.
> This means instance of PrettyClass, Parsec, and Binary. I noticed a
> number of parsing utilities for IP addresses - lots of duplicated
> effort here.
- Taru Karttunen
More information about the Libraries