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
> specifie
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
file:///
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, Grah
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 so
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 the
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:
http://developers.sun.com/
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, trea
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 n
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 mySoc
At 14:05 12/05/05 +0200, Peter Simons wrote:
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].
#g
--
[1] ftp://ftp.rf
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 multipl
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 use
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
13 matches
Mail list logo
