In article <20051106102654.GA4531 at yui.aoinet>,
Einar Karttunen <ekarttun at cs.helsinki.fi> wrote:
> On 05.11 18:29, Ashley Yakeley wrote:
> > It's quite low-level, isn't it? I wonder if it would be worth doing
> > something along these lines:
> >
> > newtype IPv4Address = IPv4Address Word32
> > newtype IPv6Address = IPv6Address Word128
>> This brings the question on whether they would be native or
> big endian -
This should be unambiguous. For instance, in the address 127.0.0.1, 127
is the high Word8 of the Word32.
> and the user would still need to use resolver API to get at these.
That could be a function in InternetService:
type DomainName = String
data InternetService addr = MkInternetService {
...
dnsLookup :: DomainName -> IO (Maybe addr), -- or similar
...
}
> Does it make sense to have the address type in there?
> Most of the time high level applications should not
> care whether the socket is IPv4 or IPv6 (or something
> entirely else). One of my main goals has been to
> make the protocols transparent - changing from IPv4
> to being protocol agnostic should be as easy as possible.
This is a good application for polymorphism on the address type.
> The API you are suggesting would be certainly quite
> easy to implement on top of the current one. If you
> can specify the interface you would like I think
> I can include something like that in the next release...
What you have is close to the C sockets API. It's probably best not to
mix the high-level and low-level stuff. Probably there should be some
wider discussion on what the best approach is, especially as there's
some impetus for reform of the file APIs also.
--
Ashley Yakeley, Seattle WA