[Hessian-interest] Protocol extension: type negotiation

[Ben Hood]

Hi, In the current 2.0 spec, object type information is send once per *Hessian interaction* (a loosely defined concept) and subsequent instances of a type simply reference this type definition. This makes Hessian quasi-stateful within the context of a single interaction. I can only assume that a type reference is only valid within a single call, reply or message. This means that the scope of a type reference is bound by The c and the z of a call The r and the z of a reply The boundaries of a single non-final or final message packet Given that I was wondering whether there is any merit in making the scope of a type reference more explicit and stateful, so that it can be re-used across invocations. This would reduce the amount of redundant type information that is sent over the wire. I've attached an interaction diagram of how a mini-protocol to exchange type information might look. In this interaction, a peer who wants to send an instance of a type does the following: Irrespective of whether it has already sent the other peer the type information, it sends an instance with a type reference. The other peer does not recognize the type reference so it requests to have the reference resent. The initiating peer resends the type reference. The initiating peer resends the instance data. The initiating peer proceeds to send more instance data.  There are a few considerations around this: Should peer 2 be required to buffer the instance data sent in (2) pending the resend of the type information instead of resending the instance data as in (4)? This means that peer 2 takes responsibility for the data it has already received although it doesn't yet have any type information for it. The type reference request is idempotent. This means that any peer can request any type reference whenever it wants. The implication of this is that a peer can send any instance data irrespective of whether it has previously sent the type information or not, provided it can answer subsequent queries to the references it sends. This also means that you would also have to deal with invalid reference queries. Any discussions, comments or suggestions are appreciated, Ben

Hessian Type Mapping.pdf
Description: Adobe PDF document

_______________________________________________
hessian-interest mailing list
hessian-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/hessian-interest