Hi, Don't know whether there's any other interest in this topic, but in addition to what I had previously posted about type negotiation, it occurred to me that dynamic type mapping (as described in Scott's metaprotocol taxonomy) is not necessarily the complete picture of end to end interoperability.
The taxonomy describes Hessian as "a protocol [that] can use any reflective, statically-typed object-oriented language as its description language". This implies that it can introspect the necessary type information to either 1. Write type information on the fly from an arbitrary type or 2. Read foreign type information and generate a native instance from the wire format data. I would argue that while this is true, this will only work between peers that have some implicit a priori type agreement as is the case when 1. Peer 1 in Java speaks to Peer 2 in Java with the same version of the communicated object definitions. 2. Peer 1 in language x speaks to Peer 2 in language y and they implicitly use a standard namespace, method naming and field accessor mechanism. However, what happens in case (1) where the versions of the types are different? What happens in (2) when any language conventions are not upheld (e.g. not using JavaBeans) or if you use a non-OO language. The short answer to question 2 is to just say as the taxonomy does: Hessian will only work for reflective, statically typed OO-languages (How does the C++ implementation work....?) My point is that you implicitly have to have a static understanding of the type information otherwise you can't intelligibly speak to each other. On the other hand, you want to minimize the overhead of generating static type information (e.g. compiling stubs and skeletons). Hence I feel that being able to express type information on the fly in commonly understandable format is a good thing. I think this type information should 1. Be standardized so that it can be interpreted by any type of language, including non-OO languages 2. Be explicitly negotiated because each peer will have to have a common understanding of the semantics for it to work anyway. 3. Only be sent on request by the receiver, so that redundant type information need not be resent. Anyway, only my $0.02, Ben On 13 Dec 2007, at 23:14, Henric Larsson wrote: > 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 _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
