From: Bernhard Brodowsky <lists@...>
Date: 2012-09-05T03:25:46+09:00
Subject: Re: Socket Decorator

Bernhard Brodowsky wrote in post #1074676:
> Jeremy Bopp wrote in post #1074640:
>> On 09/04/2012 07:34 AM, Bernhard Brodowsky wrote:
>>> having to implement all the gets puts send recv etc myself?
>> Take a look at the io-like gem:
>>
>>   https://rubygems.org/gems/io-like
>>
>> It provides a fairly easy way to emulate the IO interface; however, I
>> haven't updated it yet to emulate Ruby 1.9 IO details.  Ruby 1.8.7 is
>> the limit for now.
>>
>> -Jeremy
>
> Thanks a lot, that is almost exactly what I was looking for. But there
> is a slight twist in my application: I cannot do unbuffered_read() for
> an arbitrary length in my case because the transformations operate on
> blocks and my transformations may even change the length of the part I
> read in an unpredictable way, which makes it impossible in the first
> place to read a given number of bytes. There is an easy workaround for
> this, namely that I can use another internal buffer for my
> transformations and read as much as necessary to achieve a given length,
> but it is a little inefficient and not very elegant to do so, because
> then my read operation is not really unbuffered and there exist two
> buffers on the different layers.
>
> A much larger problem is the fact that I usually work with sockets. With
> sockets, I cannot do "unbuffered_read" for an arbitrarily large length
> since the other side may simply not have sent enough yet. I didn't look
> at your implementation yet, but I guess if I call gets, you probably
> read subsequent larger parts (let's say of size N) using the
> unbuffered_read operation in some way until you find a newline
> character. But if the other side just sends "\n", gets should not block,
> but deliver "\n" directly, but if you try to read N bytes, it would
> block.
>
> So your library seems nice in the case if the underlying IO object is a
> File or something similar, I guess that is also the application you had
> in mind when you wrote it, but for sockets, it is probably a little
> harder.

Ok, I started looking at the code and I noticed that the library is much 
more than expected, the code is really very well documented and nicely 
written, I also think I can solve all the problems I mentioned, for 
example I could set fill_size to 0 to disable buffering by your code and 
then do buffering in my code to achieve the required lengths in 
unbuffered_read. I still need to figure out some things, for example 
your code heavily relies on the exceptions I throw and I have to figure 
out which ones I have to throw in which occasions such that all things 
like blocking and non-blocking reads work properly and what I have to do 
to end the connection suddenly without your code catching it and I will 
have to watch out if there are occasions where a call to 
unbuffered_read() blocks because not enough data is available where it 
should not or should throw an exception instead.

-- 
Posted via http://www.ruby-forum.com/.