Cleaner networking API - network-fancy
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/Net... 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
On Thu, Aug 13, 2009 at 9:14 AM, Taru Karttunen
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/Net...
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?
There is already a getHostName in Network.BSD, any reason for not using it? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
Thank goodness for a cleaner networking API. I almost chose Haskell's socket API as an example of what _not_ to do in my series on Good API Design (http://jdegoes.squarespace.com/journal/2009/5/11/good-api-design-part-3.html ). Ended up going with Java though. :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Aug 13, 2009, at 2:14 AM, 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/Net...
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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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/Net...
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.
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.
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.
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.
Thomas
On Thu, Aug 13, 2009 at 10:45 AM, Bardur Arantsson
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/Net...
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, Aug 13, 2009 at 8:09 PM, Thomas
DuBuisson
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
Excerpts from Johan Tibell's message of Thu Aug 13 21:41:51 +0300 2009:
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.
+1 I would be interested in participating in this. - Taru Karttunen
Excerpts from Thomas DuBuisson's message of Thu Aug 13 21:09:38 +0300 2009:
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.
UDP does not play nicely with Handles. TCP wants Handles. Thus using an unified API does not make much sense. The semantics are just too different. - Taru Karttunen
participants (6)
-
Bardur Arantsson -
Johan Tibell -
John A. De Goes -
Magnus Therning -
Taru Karttunen -
Thomas DuBuisson