Potential Network SIG

[Thomas DuBuisson]

Bryan O'Sullivan wrote:
> Your agenda is very ambitious, which worries me a little. As a "how to get
> things moving" tip, I'd very strongly suggest trying to make progress on the
> lowest level bindings first, as they will be the most concrete, and the
> least likely to provoke prolonged discussion and disagreement.

Thanks for the tip - I'll probably do that.  It's my intention to
reuse much of the current Network low level bindings.  It still
doesn't have all the constants we want... and it has some extra fluff
such as inet_ntoa, but its a great place to start.

>> 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).
>
> I don't understand what this might mean. Code examples or type signatures
> are going to be much easier to follow than English descriptions.

Network.Fancy (and Network.Socket) defines a data structure morally
equivalent to:

    data Address = IPv4 Word32 | IPv6 Word128 | ...

I Object!  Code that uses addresses _might_ be very specific to IPv4
or IPv6 - such code should be able to restrict itself to the proper
category of addresses, headers etc without resorting to partial
functions.  I propose a solution akin to:

    class Address a where ...
    instance Address IPv4
    instance Address IPv6

This could allow connect functions, such as those in Network.Fancy, to
look like the below signature.

     connectDgram :: Address a => a -> IO Socket

While still giving type safety to those of us who do low level munging
with protocol headers.  I'm still not clear on how the routines would
be built - this idea was born from a desire for type safety when
building headers.

>> 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).
>
> Providing Network.Windows and Network.Linux and Network.BSD etc modules
> would work fine for non-portable platform-specific features (of which there
> are many).

I was actually thinking of even rarer platforms that might not even
have a concept of Sockets (halvm anyone? House, hOp?) - keeping
important data declarations separate from IO allows such platforms to
provide their own IO but not have to rebuild everything in a manner
incompatible with the rest of hackage.

> As for providing instances for the likes of Binary, there are good reasons
> not to do that in the core network package, because it will drag in
> dependencies on quite a few third-party packages that are either not in core
> (binary) or have questions over their futures (Parsec).

I understand the issue, but it would be a shame if a new network
package failed to have functional Address parsing - its just such a
basic thing.  I suppose this gives even more weight to a dual package
solution.

Thomas