On Jan 7, 2008, at 4:40 PM, Ben Hood wrote: > > This implies that it can introspect the necessary type information to > either > > 1. Write type information on the fly from an arbitrary type or
Hessian does this. > 2. Read foreign type information and generate a native instance from > the wire format data. Hessian does this, if the type name matches. We will need to add some kind of mapping to the hessian implementations to map type names for cases where they don't match. > > 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. The point is that Hessian is flexible with version changes. For example, if a new version adds a new field, the old object will still get the data from the old fields, and ignore the new field. If the types change (within reason), Hessian can handle the field types, e.g. from int to long or double. So a new version client can communicate with an old-version server, or an old-version client can communicate with a new-version server, as long as the changes are reasonable. > 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. The namespace and fields are the main issue. You can't just rename field "foo" to field "bar" and expect those changes to be handled automatically. So it is assumed that both ends use similar package names, for example. Basically, both sides need to agree with the same API, as if you wrote a reflection-based program to automatically convert one to the other, just like CORBA's IDL. > However, what happens in case (1) where the versions of the types are > different? Hessian is flexible with changes, since it sends the field names and types all of its values. As long as the versions don't radically change types, but just add and delete, it's handled automatically. > What happens in (2) when any language conventions are not upheld (e.g. > not using JavaBeans) or if you use a non-OO language. JavaBeans is a non-issue. The field names come from the local conventions, e.g the actual field names or for JavaBeans the JavaBeans methods. On the C#, side the field names would probably be actual field names. Non-OO languages just use the raw field names as object fields. It's not an issue. > > 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....?) C++ would need to be generated programmatically from a reflective definition (e.g. Java or C#) , just like for IDL. > 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. Only in the case of obsolete languages like C++. The two sides certainly need to agree. You can't just send random classes and expect the other side to word. The end protocol still needs work and agreement from both ends, especially with regards to the semantics. There's still a considerable amount of work needed to define the end-protocol, i.e. the meta-protocol is just a tool. Hessian still has a defined API which specifies the protocol (usually written in Java or C#). That definition is automatically convertable to any typed language, and serves as a general reference document. > On the other hand, you want to minimize the overhead of generating > static type information (e.g. compiling stubs and skeletons). That's only needed for the obsolete languages like C++. > Hence I feel that being able to express type information on the fly in > commonly understandable format is a good thing. Why? I don't see any value to this at all. -- Scott > > 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 > _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
