On 5 sept. 2010, at 03:22, Schwab,Wilhelm K wrote:

> Noury,
> 
> I was struggling a little with a stream for serial ports, and thought you 
> might have tackled the problem of a generating stream (one that can grow in 
> the background).  Now that I type that, maybe Nile has the answer?? 
> 
> Re Ocean, I grabbed a .mcz from SqueakSource and simply browsed the main 
> package.  Some comments: 
> 
> (1) no socket stream :(   Streams are really slick things, and good read and 
> write stream semantics should exist for sockets.  FWIW, Dolphin separates the 
> socket read and write streams, and we might do well to follow their lead.
> 
Not yet ;-)
So far, we want to have a clean socket. And then we'll rebuild a SocketStream 
on top of it.

> (2) ByteArray>>asAlien loops over the bytes.  Do all the bounds checking you 
> want up front (once) and then use memcpy() or something to actually transfer 
> the data.  It recently came to my attention that Squeak has no formalized 
> approach to access, copy and move external memory; Pharo needs to offer that, 
> and this is a good place to start.
> 
Thanks for the hint.

> (3) You are planning to attack ipv4 vs. 6 with polymorphism - good call!!
> 
Yes. One reason behind doing Ocean is that we found existing library too dirty 
to improve.
So, we try to have a well designed tested library.

> (4) OCNTcpSocket>>send: sizes a buffer to match the data provided to it.  I'm 
> not sure I like that.  You might consider renaming your current #send: to 
> #basicSend: and adding something like
> 
> send:blob
> | in |
> in := blob readStream.
> [ in atEnd ] whileFalse:[
>   self basicSend:( in nextAvailable:self alienDataBufferSize ).
> ].
> 
> so that a fixed buffer (which will have to be allocated when the socket is 
> opened) is used to send large blobs in buffer-sized chunks.  Better still 
> would be to use array indexing to cope with the blob in pieces but in place 
> to skip the copying.
> 
We discussed this with Luc. And the rational behind our decision to do it this 
way is that Socket is but a basic wrapper for the actual OS socket.
It shouldn't provide any extra features.

Spliting a blob is something I'd rather do by using a SocketStream.

Thanx for the feedback,
Noury



_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to