--- 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. 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?

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

Reply via email to