Hi, Just wanted to chime in on this. I think it's an excellent idea that would would be of great benfit for long running session with many small invocations. My first thought around this though was to have an explicit session negotiation occuring, initiated by the peer that wants to use a long running session. Just for the sake of being explicit about the session and also allowing for fallback to sessionless invocation. Although having the reciever request a resend would probably work just as well.
What's the cacho people's thoughts on this? Cheers, Henric Larsson On Dec 7, 2007 9:42 AM, Ben Hood <[EMAIL PROTECTED]> wrote: > 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-interest mailing list > [email protected] > http://maillist.caucho.com/mailman/listinfo/hessian-interest > > -- .henric.larsson. _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
