Thanks Scott, I regret I ignored these important enhancements with 2.0, but seems I was reading spec 2.0 draft 1 before, and somehow misleaded by the following statements in the "Design Goals" paragraph:
"Hessian 2 is a compaction of the Hessian protocol. All Hessian 1 codes are understood by Hessian 2. The extended codes provide compact formats for common values, e.g. storing an integer zero as a single byte instead of Hessian 1's 5 bytes." I was part of the problem that wrongly assumed there are no much big differents between 1.0 and 2.0 beyond shortened integer formats. Now I read spec 2.0 draft 2 and saw this phrase gone. I reached the old draft 1 of spec 2.0 by navigating through links at header & footer of spec 1.01, so I had thought that's all of present hessian specifications. I suggest spec 2.0 draft 2 be linked to draft 1 or just replace the links at spec 1.01 and elsewhere to avoid others make my mistake easily. And after reading spec 2.0 draft 2 I found it rather ideal, I'll base my work on this latest version as much as possible. Thanks for the music! Best Regards, Compl On 8/13/07, Scott Ferguson <[EMAIL PROTECTED]> wrote: > > On Aug 10, 2007, at 8:35 PM, Emil Ong wrote: > > > --- Compl Yue Still <[EMAIL PROTECTED]> wrote: > > > >> 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. > > You're right that the type names and field keys can be compressed > from Hessian 1.0. > > But Hessian 2.0 already does that. :) > > Each map or list Type establishes an implicit reference (like the > object reference) and can be referred to in a following instance. > > e.g. the first instance would be > > M t x00 x08 qa.Hello > ... > z > > while a following one would look like: > > M x75 x90 > ... > z > > x75 is the type reference. The x90 is integer 0. A different type > might be x91, x92, etc. > > In Hessian 2.0, objects can be compressed even more from the map to > avoid repeating the field names. The definition looks like: > > O # object def implicitly creates ref like the object ref > x00 x08 qa.Hello # type > x92 # number of fields > x06 fieldA > x06 fieldB > > The instance refers to the definition and can avoid the field and > type entirely: > > o x90 # refers to object def #0 since x90 is integer 0 > x05 Hello # string data for fieldA > x95 # integer data for fieldB > > >> 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. > > There are a few difficulties with this specific notation. > > First, Hessian 2.0 already saves list instances, object instances, > object definitions, and types. So the only largish types left > unsaved are strings and binary data. > > More importantly, because Hessian is a single-pass serialization > protocol, it's not possible for Hessian to know if an object or > string will be reused. The def/ref pattern essentially implies a > two-pass serialization, which we definitely want to avoid. > > In the case of the .class file, the Java compiler knows every single > string, double, method, etc that's used in the .class before it > begins writing out the data. So it doesn't need to rely on > heuristics to guess which objects will be used and can be a bit more > efficient. > > >> > >> 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. > > Since it's related, there is a "streaming" mode for Hessian 2.0. > (The 'P' message introduces it.) > > After each top-level object in the stream, the object reference map > is reset (see Hessian2Input.resetReferences()). However, the type > map and the object-definition map are not reset in streaming mode. > So in long-lived Hessian streams, the type names and field names are > only sent once, which is what you're looking for. > > -- Scott > > > >> > >> What is your evaluation, does it worth to be added to the protocol? > > > > Hi Compl, > > > > This is a pretty interesting idea. I would rephrase it as adding > > instance references rather than constants. Scott, what do you think? > > > > There are a couple of possibilities in the meantime. Basically the > > compression you're suggesting is like an explicit form of gzip (sort > > of), so you could just use gzip for your application now. The other > > thing we've got going is a Hessian/REST implementation that features > > caching for HTTP GETs. That would reduce processing time in certain > > applications. > > > > Thanks for the suggestion! > > > > Emil > > > > ============================================================ > > > > Emil Ong > > Software Engineer > > Caucho Technology, Inc. > > Tel. (858) 456-0300 > > mailto:[EMAIL PROTECTED] > > > > Caucho: Reliable Open Source > > --> Resin: application server > > --> Quercus: PHP in Java > > --> Hessian Web Services > > > > > > _______________________________________________ > > 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
