Subject: Re: [Haskell-cafe] Re: Cleaner networking API - network-fancy - msg#00363

Previous Message by Date: click to view message preview

[Haskell-cafe] Re: Cleaner networking API - network-fancy

Taru Karttunen wrote: Hello network-fancy offers a cleaner API to networking facilities in Haskell. It supports high-level operations on tcp, udp and unix sockets. I would like some feedback on the API http://hackage.haskell.org/packages/archive/network-fancy/0.1.4/doc/html/Network-Fancy.html In particular: * Does the type of the server function in dgramServer make sense? or would (packet -> Address -> (packet -> IO ()) -> IO ()) be better? * Does the StringLike class make sense? * Any other suggestions? - Taru Karttunen One thing that seems to be missing (and also seems to be missing from the GHC standard libraries AFAICT) is listening for multicast UDP. This requires some extra socket gymnastics to handle group membership. The details can be found in the network-multicast package. Cheers, -- /me who wonders where his signature went. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@xxxxxxxxxxx http://www.haskell.org/mailman/listinfo/haskell-cafe

Next Message by Date: click to view message preview

Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)

On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes <john@xxxxxxxxxxx> wrote: What if you have another program, written in C or something, that monitors a file for changes, and if so changes the contents of another file? Surely to catch that you must mark *all* file system access as "interefering"? Even worse, another program could monitor the state of a file and conditionally disable thet network driver, now file access interferes with network access. A compiler or runtime system can't know about these kinds of things -- unless perhaps you push the effect system into the operating system (interesting idea). The best you can do is ensure the program itself is correct in the absence of interference from other programs I think the best you can do is make sure any code which is vulnerable to such interference won't be subject to unsafe transformations (like changing the order of evaluation).  So I do think pretty much anything that relies on the outside world needs to go into one big effects "category" so the compiler/runtime will "stay out" and let the programmer explicitly define the ordering of those operations, precisely because the compiler has no way of knowing anything about what kind of assumptions are in effect. -- Sebastian Sylvan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@xxxxxxxxxxx http://www.haskell.org/mailman/listinfo/haskell-cafe

Previous Message by Thread: click to view message preview

[Haskell-cafe] Re: Cleaner networking API - network-fancy

Taru Karttunen wrote: Hello network-fancy offers a cleaner API to networking facilities in Haskell. It supports high-level operations on tcp, udp and unix sockets. I would like some feedback on the API http://hackage.haskell.org/packages/archive/network-fancy/0.1.4/doc/html/Network-Fancy.html In particular: * Does the type of the server function in dgramServer make sense? or would (packet -> Address -> (packet -> IO ()) -> IO ()) be better? * Does the StringLike class make sense? * Any other suggestions? - Taru Karttunen One thing that seems to be missing (and also seems to be missing from the GHC standard libraries AFAICT) is listening for multicast UDP. This requires some extra socket gymnastics to handle group membership. The details can be found in the network-multicast package. Cheers, -- /me who wonders where his signature went. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@xxxxxxxxxxx http://www.haskell.org/mailman/listinfo/haskell-cafe

Next Message by Thread: click to view message preview

Re: [Haskell-cafe] Re: Cleaner networking API - network-fancy

On Thu, Aug 13, 2009 at 8:09 PM, Thomas DuBuisson<thomas.dubuisson@xxxxxxxxx> wrote: > I'm considering putting not insignificant effort into reworking the > Network API during HacPDX.  Assuming Johan agrees with the changes > (and I don't know exactly what those are yet), I'd like to leave > Network.Socket for general use and rework the Network module to allow > easier TCP/UDP sending and receiving, binding to particular IP > addresses, using bytestrings, receiving data with IP Headers, and > sending with IP headers.  Multicast is another good idea that should > be in there. Designing a correct and usable socket API is difficult. There are lots of corner cases that are easy to get wrong. For example, the current socket API always throws an EOF exception if recv returns a zero length string even though a zero length return value only indicates EOF when using TCP! Furthermore, the current API uses Strings which makes no sense. The library is poorly documented and lacks test (compare it to e.g. Python's socket module). There are other pitfalls as well. If you only cover parts of the BSD API you will alienate a fraction of your users who are forced to write their own bindings, not an easy task, especially if you want the binding to be cross platform. This applied to any OS binding. My best advice would be to form an special interest group (SIG) and iron out the details. This doesn't have to be anything terribly formal. Just a bunch of people who are interested in improving things. The SIG could keep a wiki with the current design. This makes it easier for both the members and other interested developer to review the design and find flaws. >> In general, the community would probably benefit if all these small > packages (network, network-data, network-fancy, network-bytestring, > network-multicast, network-server) gave way to fewer, more complete > packages. I absolutely agree. Hackage has increased the number of libraries a lot, which is great. However, great libraries often come out of peer reviews and attention to detail. As for network-bytestring, it is slated to be merged back into network under Network.Socket.ByteString if it passes community review. > Right now the thought has came to me that the cleanest, most uniform > method might be to have a Config data type with all these ideas as > options and use a single 'connect', 'listen' or 'receive' function for > all the different protocols and their various options.  I'll think on > it. Write a wiki and explain how nicely this idea solves some of the current issues. That would be a good start. Just my 2 cents, Johan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@xxxxxxxxxxx http://www.haskell.org/mailman/listinfo/haskell-cafe