At 12:03 15/05/05 +0200, Peter Simons wrote:
Graham Klyne writes:
The longer I think about this whole thing, the more I am
convinced that using URIs is the answer.
FWIW, the revised URI parsing code [2][3] in the latest
libraries includes support for IPv6 literals, as
specified by
Graham Klyne writes:
The longer I think about this whole thing, the more I am
convinced that using URIs is the answer.
FWIW, the revised URI parsing code [2][3] in the latest
libraries includes support for IPv6 literals, as
specified by RFC 3986 [1].
Thanks for the pointer, Graham. I
Ravi Nanavati writes:
http://developers.sun.com/techtopics/mobility/midp/articles/genericframework/
It does look quite interesting. We'd probably need only a
fraction of all those options, but the schemes
socket://www.j2medeveloper.com:80
datagram://www.j2medeveloper.com:7001
Peter Simons [EMAIL PROTECTED] writes:
Judging from a quick glance, the code seems to marshal the
POSIX API:
type SockAddrLen = Int
data SockAddrT
type SockAddr = ForeignPtr SockAddrT
data SocketAddress = SA !SockAddr !SockAddrLen
I'm not sure whether that's a useful
Einar Karttunen writes:
Lifting [network address information] to Haskell level
seems quite pointless, as it is usually just fed back to
the C functions.
Well, I certainly _do_ need it.
The current way is to ignore adress families as much as
possible while still supporting multiple
Peter Simons [EMAIL PROTECTED] writes:
Lifting [network address information] to Haskell level
seems quite pointless, as it is usually just fed back to
the C functions.
Well, I certainly _do_ need it.
You can certainly get it:
getHost mySocketAddress niNumerichost
getServ
Einar Karttunen writes:
Well, I certainly _do_ need [a representation of network
addresses in Haskell].
You can certainly get it:
getHost mySocketAddress niNumerichost
getServ mySocketAddress niNumericserv
Um, yes, but 'String' isn't a very good representation for
manipulating network
Peter Simons [EMAIL PROTECTED] writes:
[URIs might be the answer]
But what URI should represent e.g. unix datagram sockets?
I don't think it's worth even trying to hide both stream-
and packet-oriented services behind the same API. These are
completely different things, treated them
Einar Karttunen wrote:
But what URI should represent e.g. unix datagram sockets?
Having an URI connection function would be nice, but having
it as the primary alternative would not be very nice.
Could URI schemes like those in the Java Generic Connection Framework
(see:
On Thu, 12 May 2005, Marcin 'Qrczak' Kowalczyk wrote:
But they don't differ in addressing. In BSD sockets the difference
between streams and packets lies in socket type, while addresses
are split into address families which bijectively correspond to
protocol families.
I believe there are
Tony Finch [EMAIL PROTECTED] writes:
But they don't differ in addressing. In BSD sockets the difference
between streams and packets lies in socket type, while addresses
are split into address families which bijectively correspond to
protocol families.
I believe there are some obscure
Shae Matijs Erisson writes:
Einar Karttunen's network-alt supports IPv6, datagram, and more:
http://www.cs.helsinki.fi/u/ekarttun/network-alt/
Duh, I didn't even know this library existed! Thanks for the
pointer.
Judging from a quick glance, the code seems to marshal the
POSIX API:
type
12 matches
Mail list logo
