Johan - glad you chimed in! I'm all in favor of keeping a low level interface and don't have an issue with Network.Socket existing, I additionally really like the suggestion of moving from the ML to a wiki in the same style as Haskell'.
I'll port these comments to the wiki if that is whats agreed on and hold off on other thoughts for now. * ByteStrings! Absolutely. The one issue is I feel network packets should be represented as strict bytestrings and any encode/decode issues resulting in a 'Left err' via binary-strict or some beefed up version of that package. * Avoiding a 'heavy weight' solution for socket state might get ugly fast with all the 'Either a b' results that we'll need - also a socket can close at any time so a socket in 'Connected' state might not actually be connected. I understand the attraction to a light solution using existential types but Tim Sheard sketched for me a reasonable alternative which I invite him to restate here, if he has the time. Thomas On Mon, Jun 22, 2009 at 12:16 AM, Johan Tibell<[email protected]> wrote: > On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson > <[email protected]> wrote: >> >> I'm in favor of the entire Network library being reworked with an >> improved API that is higher level and type-safe instead of a direct >> translation/FFI of Berkeley sockets. I also would like the Network >> package to export Data instances for headers while taking advantage of >> pretty, prettyclass, and parsec. I started such work with >> network-data but never really got off the ground with it. > > I've given this some thought. There are a few different things that would be > nice to have in a new API: > > * Use a binary type (e.g. ByteString) instead of Strings. (see > network-bytestring) > * Encoding more things in the type system, in particular the socket state > (opened, closed, connected, etc). I would like to avoid a very heavyweight > encoding though. > * Allow folds over the input i.e. foldSocket :: (a -> ByteString -> a) -> a > -> Socket -> IO a > > I'm all for having a higher level API but I would like to keep the Berkeley > socket interface. The reason is the following: If we provide a higher level > API that does not expose the whole underlying OS API there will be some > users who can't use the library and will have to resort to writing their own > bindings. I've seen this problem in a few other libraries. The reasoning > often goes something like this: This interface will cover 90% (or 95%) of > all the use cases so its sufficient for most people. The problem with this > kind of reasoning is that I have to write my own OS bindings for every ten > libraries I use (on average). > > Perhaps we should start a wiki page where we can take some notes on things > that could be improved in the style of Haskell' discussions (i.e. outlines > of the problem together possible solutions together with their trade-offs. > Python's PEPs are a good model here)? > > -- Johan > > > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
