Dear Hessian Team,
First, THANK YOU for the beautiful specification of the Hessian protocol.
It has been a guiding light through our searches for an efficient, low
complexity binary protocol.
We started using and reimplementing it in our Java and C# apps. As such,
we hit a few problems. v2.0 of the spec presents an opportunity to fix
these small details with the protocols.
1. Type of Map and List
Problem: it would be great to be able to store XML directly in Hessian
structures. The Map type is well suited to this, except that element
attributes cannot be fitted into a string. Same with Java annotations,
they would fit great into an extended type object. There is more to a type
than just its name.
Fix: Currently the type is an optional string. In my opinion, it should be
a mandatory object. Lack of type information would be represented by Null.
The 't' tag can be removed.
Syntax:
type ::= object
map ::= 'M' type (object object)* 'z'
list ::= 'V' type length? object* z
2. Object Definitions and Instantiations
Again, excellent work! This greatly reduces the size of the protocol and
improves its speed. Unfortunately, it is unnecesarily less general than
the Map type.
Problem:
a. Not all maps use strings as keys.
b. packing the definition together with the first data instance places
an additional burden on the writer, because the object definition
reference is not known until the first item is written. The initialization
and usage phases get blurred. What if there are multiple threads writing
in the same Hessian stream? Which one defines the object?
c. to keep track of object definition references the algorithm needs
to keep track of map references. There can be potentially hundreds of
millions of map references. The naive algorithm leaks memory while
allocating references.
Fix:
a. allow objects instead of strings for object definitions keys.
b. remove all data from the object definitions.
c. separate Object Definition references into a different namespace
than normal map references. Eg the object definition reference increases
by one for each object definition, not for each map, list or object
definition.
map ::= 'O' int type-object int object*
int - assigned reference (see next point)
type-object = object = complex structure representing the type of the
map
int - number of fields.
object* - fields types
3. References
Problem:
a. Current references are automatic, requiring the reader to keep
track of all previous objects in the stream. For streams of millions of
objects, that would use the memory very fast or require more complicated
read back algorithms.
b. Assume a multi-threaded architecture using multiple Hessian sources
writing into one stream. Because of the positional nature of the
references, the writers would need to obtain a reference from the Hessian
stream and keep the stream locked until they write all their data, less
the stream is being written by another thread and their reference
invalidated.
Fix:
It would be nice if the reference could be assigned by the writer
instead of being assigned positionally by the Hessian library.
Introduce a special BookmarK (Reference Definition) construct before
any object which is to be referenced.
ref ::= 'k' b32 b24 b16 b8 // bookmarK
I am not keen about this point, as it would require a lot of
rearchitecting, but IMHO in a better world, this is how references would
work.
4. Compact Ints
Problem: a. Extra Complexity. The definition and implementation of ints
are no longer trivial. The set of tags also greatly increases, to include
int values.
b. Less future extension tags possible.
Pro: It is TEN times faster (Hessian2: 30 million integer writes per
second, vs 3 million in Hessian1) and two times smaller in a
micro-benchmark for integer writes.
Comment: Is the extra complexity and harder future extension worth the
smaller size and faster speed?
5. Version Naming
Problem: confusion in versioning. There is Hessian 1.0.2, 1.0, V3 and V2,
in that order.
Fix: it would be great if they were in order :-)
Implementations
We will be happy to provide our implementations of the above changes for
C# and Java, when they are approved. We will also post a Hessian2Text
utility and HessianViewer for spec 1.0.
Regards,
Rares Ispas
rares at raisoftware dot ro
RAI Software, Romania
_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest
