Hello Hessian Guys, I found the ideas of hessian rather excellent when choosing a wire protocol for inter-component communications in a new open source framework I'm starting.
However after some investigation and initial work, I got an idea to further compact the traffic by introducing a mechanism of constant pool. This ideas comes from the class file format and runtime handling of symbolic linkages in the JVM specification. Here in hessian we can just maintain a runtime constant pool at each side per connection, to store type names, map keys and other values those can be treated as constants, and tends to be reused repeatedly over time. I suggest a C object notation to add an object to the constant pool at both sides, at the next free index, and later the notation p b32 b24 b16 b8 can be used to reference the constant value by its index, where a value is expected. This is somewhat like how ref is handled. I can see reasoning why this mechanism is not included in current specification of hessian that the web-service nature implies most connections are short-lived so such a mechanism makes little sense in bandwidth saving, besides the complexity it will bring. However I don't know if long-connections commonly exist in current hessian world, at least my scenarios would be like so, and I think it might be similar when short hessian connections are pooled for reuse over time. In such cases I suppose the constant pool would same even more bandwidth than the compaction by spec version 2.0, considering long (java) type names and overly used field names. What is your evaluation, does it worth to be added to the protocol? Best Regards, Compl _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
