On 5 Dec 2007, at 04:26, Emil Ong wrote:
That's exactly right. One of the motivations that I didn't really go
into is also that this change makes it much easier to write a
streaming
reader when dealing with non-blocking I/O. That is to say, it makes
reading much easier for Flash ;-). Flash is completely non-blocking
and
if we didn't know where object boundaries were, we would have to
restart
parsing objects every time we received data. Putting things in
packets
basically gives the encoded length of the object, which means we don't
need a stateful parser. We can just buffer until the whole object is
there, then use the existing parser on that buffer.
Fine, AS3 only runs in a single thread which limits it's IO handling
capabilities to only being able to respond to asynchronous events. But
what happens when the socket that the Flash VM is listening to sends a
progress event before it itself has buffered at least enough data to
completely consume at least one of the Hessian packet messages you are
sending it? The following socket event handler illustrates what I am
talking about:
private function onSocketData(event:ProgressEvent):void {
while (sock.bytesAvailable > 0) {
// Marker will be the P code
marker = input.readUnsignedByte();
length = input.readUnsignedShort();
// What happens when sock.bytesAvailable < length ?
}
}
As far as simplicity, I think given the goal of giving the encoded
object length, this approach is about as bare-bones as you can get.
Granted. But the question I was asking was whether you actually really
need the encoded object length. If you answer yes to that question,
then I agree, this approach is fine.
Ben
_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest
