Re: [Haskell] Re: Existing Haskell IPv6 Code
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 RFC 3986 [1].
Thanks for the pointer, Graham. I knew that the URI code had
been written a while ago, but never realized how extensive
the changes were! Great job.
Thanks! (It's essentially a complete rewrite.)
Now the only problem is that the module doesn't expose the
functions we would need; such as Network.URI.host, for
instance. Would it be possible to factor those parser out
into a
Text.ParserCombinators.Parsec.Rfc3986
This seems a reasonable idea.
module? Maybe we could even merge those parsers with the
ones I have here:
http://cryp.to/hsemail/docs/index.html
RFC grammars are often very similar after all.
I think it could be useful to have a collection of RFC parsers along these
lines. I'm not entirely sure what you mean my "merge" -- I think the RFC
distinctions should be maintained.
One might also consider that my unit test code (see ../tests directory)
contains some framework functions that might be used to create a test case
library.
One thought: in some cases, my URI parser code depends on the URI data
types that I declare (for the return values), so it might not separate as
cleanly as one might like -- I think it would be confusing if the data type
declarations were separated from the URI module. I suppose the parser
combinators might return tuples that are assembled by the URI code.
Also, if separating the combinators, one might want to make the monadic
parser type more general. Hmmm I did something like this for another
bit of code somewhere, but I forget where. I think I made the parser
polymorphic in the state value, which was not referenced. This way, the
parsers can be referenced by other, more specific combinators that do use
the state value. Currently, the state type is ().
P.S.: In the definition
host = ipLiteral <|> try ipv4address <|> regName
it looks as if the 'try' modifier should be given for the
first alternative; not for the second. I may be wrong
though.
My initial (lame) answer is that it passes all the available test
cases. More seriously, if you think there's something that breaks the
current code then a test case should be created.
Looking at the production (copy below), the first case doesn't need a 'try'
because if the initial character is a '[' then no other parse is
possible. But for the ipv4literal production backtracking may be needed;
consider:
111.222.333.mydomain.org
#g
--
*
Selected host productions:
[[
host :: URIParser String
host = ipLiteral <|> try ipv4address <|> regName
ipLiteral :: URIParser String
ipLiteral =
do { char '['
; ua <- ( ipv6address <|> ipvFuture )
; char ']'
; return $ "[" ++ ua ++ "]"
}
"IP address literal"
:
ipv4address :: URIParser String
ipv4address =
do { a1 <- decOctet ; char '.'
; a2 <- decOctet ; char '.'
; a3 <- decOctet ; char '.'
; a4 <- decOctet
; return $ a1++"."++a2++"."++a3++"."++a4
}
]]
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Existing Haskell IPv6 Code
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:///myResourceFile.res are pretty much exactly what we need. Thanks for the pointer. Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Existing Haskell IPv6 Code
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 knew that the URI code had been written a while ago, but never realized how extensive the changes were! Great job. Now the only problem is that the module doesn't expose the functions we would need; such as Network.URI.host, for instance. Would it be possible to factor those parser out into a Text.ParserCombinators.Parsec.Rfc3986 module? Maybe we could even merge those parsers with the ones I have here: http://cryp.to/hsemail/docs/index.html RFC grammars are often very similar after all. Peter P.S.: In the definition host = ipLiteral <|> try ipv4address <|> regName it looks as if the 'try' modifier should be given for the first alternative; not for the second. I may be wrong though. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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 protocol families that have more than
> one address family, which is why the two concepts exist in the API.
Single Unix Specification v3 specifies only AF_* constants, used for
both.
Linux man socket says:
NOTE
The manifest constants used under BSD 4.* for protocol families are
PF_UNIX, PF_INET, etc., while AF_UNIX etc. are used for address fami-
lies. However, already the BSD man page promises: "The protocol family
generally is the same as the address family", and subsequent standards
use AF_* everywhere.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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 some obscure protocol families that have more than one address family, which is why the two concepts exist in the API. However there's an enormous amount of code that muddles them up, but this doesn't matter for the Internet protocols. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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/techtopics/mobility/midp/articles/genericframework/ ) help unify things? - Ravi Nanavati ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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 differently is
> fine, IMHO.
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".
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Existing Haskell IPv6 Code
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 addresses, IMHO. >> [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 differently is fine, IMHO. Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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 mySocketAddress niNumericserv > That's true. However, it doesn't work with anything _but_ > IPv4 and IPv6. I think it is unsatisfactory that you need a > different function to connect to a TCP target than to > connect to a Unix stream socket. Having a separate TCP connect function is just for niceness - of course one can use an aproach to go from URIs to sockets having a case statement for each scheme. 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. - Einar Karttunen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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.rfc-editor.org/in-notes/rfc3986.txt [2] http://www.haskell.org/ghc/docs/latest/html/libraries/network/Network.URI.html [3] http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/Network/URI.hs Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Existing Haskell IPv6 Code
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 ones. E.g. the > following works with both IPv4 and IPv6 in network-alt: > > googleMainPage = do > h <- connectTCP "www.google.com" "http" That's true. However, it doesn't work with anything _but_ IPv4 and IPv6. I think it is unsatisfactory that you need a different function to connect to a TCP target than to connect to a Unix stream socket. The longer I think about this whole thing, the more I am convinced that using URIs is the answer. Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Existing Haskell IPv6 Code
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 representation. It > works, of course, but it appears that an address is > essentially opaque (unless you want to do more FFI things). > It doesn't really unify different types of network addresses > either. Note, for example, that you can't pass such an > address to the 'connectTCP' function. That is one of the few working representations. The user of the library is not aware how the socket addresses are represented internally, so it is not a problem. Lifting the information to Haskell level seems quite pointless, as it is usually just fed back to the C functions. Also IPv6 addresses sometimes need scopes - lifting this would make things even more messy. The current way is to ignore adress families as much as possible while still supporting multiple ones. E.g. the following works with both IPv4 and IPv6 in network-alt: googleMainPage = do h <- connectTCP "www.google.com" "http" hPutStr h "GET / HTTP/1.0\r\n\r\n" hFlush h hGetContents h >>= print hClose h - Einar Karttunen ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Existing Haskell IPv6 Code
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 SockAddrLen = Int data SockAddrT type SockAddr = ForeignPtr SockAddrT data SocketAddress = SA !SockAddr !SockAddrLen I'm not sure whether that's a useful representation. It works, of course, but it appears that an address is essentially opaque (unless you want to do more FFI things). It doesn't really unify different types of network addresses either. Note, for example, that you can't pass such an address to the 'connectTCP' function. Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
