IOLib Tutorial
in [Lisp]
|
Prev: [ANN] ABCL 0.20
Next: foo-user packages
From: Captain Obvious on 7 Jun 2010 07:56 KT>>> standard FFI, no standard GUI, and no standard sockets. CFFI covers KT>>> one of those. In your experience/opinion does IOLib answer the KT>>> sockets objection? ??>> ??>> What's wrong with usocket? PK> In my case, usocket was too much of a thin compatibility layer. Yes, and being minimal is exactly why it might be good as the standard sockets API. Standard is not supposed to be fancy, it is supposed to be the lowest common denominator, I think. PK> I didn't want to write an i/o multiplexer, which was a requirement, PK> over it. PK> IMHO any serious codes which utilizes thousands or tens of thousands PK> of clients will need an event multiplexer to deal with the nonblocking PK> and often asynchronous i/o. Why should I write one over usocket when a PK> very good quality one was written already? This is why I PK> think IOLib is a great library. Yep, sure. But I believe most applications do not need thousands of simultaneous clients and thus do not need i/o multiplexer -- threads should be able to cope with up to hundred of connections, I think. And so I would not rule out usocket.
From: Peter Keller on 7 Jun 2010 13:23 Captain Obvious <udodenko(a)users.sourceforge.net> wrote: > KT>>> standard FFI, no standard GUI, and no standard sockets. CFFI covers > KT>>> one of those. In your experience/opinion does IOLib answer the > KT>>> sockets objection? > ??>> > ??>> What's wrong with usocket? > > PK> In my case, usocket was too much of a thin compatibility layer. > > Yes, and being minimal is exactly why it might be good as the standard > sockets API. > Standard is not supposed to be fancy, it is supposed to be the lowest common > denominator, I think. It is only very recently (a week ago?) that I have discovered that IOLIb and cltl3 have some kind of a relation. I'm not smart enough to determine if usocket or IOLib should be part of a standard or not. > But I believe most applications do not need thousands of simultaneous > clients and thus do not need i/o multiplexer -- threads should be able to > cope with up to hundred of connections, I think. > And so I would not rule out usocket. Different things for different people, from the usocket website: "If you want a thin compatibility layer then usocket is the right choice, but if you want the full socket API then you should take a look at iolib." Every network application I intend to write in CL will use IOLib, since every one of them will require lots of buffer management, multiplexed, asynchronous I/O, and access to the full socket API, and most likely IPV6 in the near future. Later, -pete
From: Kenneth Tilton on 7 Jun 2010 16:19
Peter Keller wrote: > Captain Obvious <udodenko(a)users.sourceforge.net> wrote: >> KT>>> standard FFI, no standard GUI, and no standard sockets. CFFI covers >> KT>>> one of those. In your experience/opinion does IOLib answer the >> KT>>> sockets objection? >> ??>> >> ??>> What's wrong with usocket? >> >> PK> In my case, usocket was too much of a thin compatibility layer. >> >> Yes, and being minimal is exactly why it might be good as the standard >> sockets API. >> Standard is not supposed to be fancy, it is supposed to be the lowest common >> denominator, I think. > > It is only very recently (a week ago?) that I have discovered that IOLIb and > cltl3 have some kind of a relation. > > I'm not smart enough to determine if usocket or IOLib should be part of a > standard or not. The spirit of the OQ was, When can Lisp stop apologizing for not having the kind of socket support other languages brag about. I would presume other languages have solutions closer to IOLib than usocket. As for the standard, that's an orthogonal concern. Sockets as a de facto standard is enough, and for my money does not belong in a language spec. kt -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld |