The general contract in all other language implementations is that read() behaves like the syscall read() -- it is not guaranteed to return any number of bytes. I think we should try to follow that paradigm in all language implementations to keep things consistent:
read = try to read some number of bytes readAll = fail if you can't -----Original Message----- From: Kevin Clark [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 4:54 PM To: [email protected] Subject: Re: Ruby Thrift::Socket#read implementation 19:49 < kevinclark> re: Thrift::Socket#read impl, I think you're wrong. I don't think any transport is allowed to expect read to return the right number of bytes. read takes one argument, the _maxsize_, and read_all assures you get all the data you ask for 19:49 < kevinclark> I think that's why I had changed read to use readpartial 19:49 < kevinclark> I'm pretty sure I've spent a day thinking about htis before 19:49 < Eridius|work> ahh, I forgot about read_all 19:49 < kevinclark> I guess the question is, why have read_all as a guarenteed implementation if you expect read to always return the right number of bytes? 19:49 < kevinclark> I think read is our readpartial 19:50 < Eridius|work> possibly. you might want to double-check all usages of #read though 19:50 < kevinclark> I think I did that before 19:50 < kevinclark> but I'll do it again 19:50 < kevinclark> heh 19:50 < Eridius|work> if it turns out that #read is supposed to act like #readpartial, then that's good, I can get rid of the #readpartial and the ugly second arg I'll follow up with final conclusions. -- Kevin Clark http://glu.ttono.us
