On Thu, Dec 06, 2007 at 09:11:58AM +0000, Ben Hood wrote: > That's ok. The length and packets just need to tell us when we're done. > > Fair enough, I guess the packet length makes the receiver's buffering quite > simple. The alternative would have been to encode the encoding length of each > encoded object, e.g.
Encoding the size in the object itself makes the sender's buffering harder though. By putting it into the packet, you can just have a fixed buffer that you're serializing into, then when it fills up, you just dump a packet. If you put it into the object, you have to buffer the whole thing first or do two passes to compute the length. > We have to buffer anyway until we get the terminal packet. > > Don't you mean that you buffer until you get the enough bytes to start > decoding > the current packet and pass it on to the application? Otherwise this would > defeat the purpose of streaming, wouldn't it? We do have to wait until the terminal packet. This is again for the convenience of the sender to allow it to have a fixed size buffer. Each packet is not required to have fully deserializable data, but the concatenation of the packets is supposed to be complete object. Think of the stream at two levels: one is the object level (which is demarcated by uppercase 'P' packets) and one is the subobject level (demarcated by lowercase 'p' packets). Best, Emil ============================================================ Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:[EMAIL PROTECTED] Caucho: Reliable Open Source --> Resin: application server --> Quercus: PHP in Java --> Hessian Web Services _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
