Re: [wmii] wmii-3 configuration - in Ruby

From: Kris Maglione <bsdaemon_AT_comcast.net>
Date: Wed, 7 Jun 2006 17:15:20 -0400

On Wed, Jun 07, 2006 at 11:42:02AM +0200, Anselm R. Garbe wrote:
>On Wed, Jun 07, 2006 at 01:47:13AM -0400, Kris Maglione wrote:
>> On Sun, Jun 04, 2006 at 08:39:16PM +0200, Francis GUDIN wrote:
>> >Hello,
>> >
>> >RStyx might help:
>> >http://rubyforge.org/projects/rstyx/
>>
>> I finally looked into this and found it completely unacceptable. Just the
>> client, with limited functionality, in pure ruby, is 1,295 lines of ugly
>> code. The fully functional lib9pclient from plan9port, in C, is 1,059
>> lines of sane code and is probably a hell of a lot faster. To be fair,
>> lib9pclient depends on plan9 system headers I'm not counting and some lib9
>> functionality, but that's besides the point.
>
>libixp is much smaller than the complete lib9p* dependencies of
>Plan9 (which are about 50kSLOC including lib9, if not more). And
>libixp/client.c keeps the connection between dial and hangup, I
>don't think the client part is a bad API of libixp (however the
>server side needs polishing, I always agreed to this).
>
>A sloccount of libixp tells me it consists of 1244 lines, for
>everything (socket handling, server/client side, protocol layer,
>- only dependency are 173 lines of libcext).
>This is 1.5kSLOC vs. 60kSLOC...
Yes, I considered mentioning this after I posted. Like I said, though, I
already gave up writing libixp bindings to ruby. The interface for ixp_client
is sane, I'll admit, but I'd rather rewrite it in ruby whan write bindings. It
would actually be easier. I think, though, that I'd rather have lib9pclient
bindings, since it fully supports authentication. I think that it's somewhat
slower, though, than libixp. I haven't actually benchmarked the libs, just the
executables (wmiir and 9p), and wmiir is ~3x the speed.

-- 
Kris Maglione
The "think positive" leader tends to listen to his
subordinate's premonitions only during the postmortems.
Received on Wed Jun 07 2006 - 23:15:53 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:08:35 UTC