On Apr 18, 2008, at 12:23 AM, Ben Hood wrote:
Scott,
Sorry for being so careless with my naming.
I didn't intend to raise the impression in public that this was an
agreed and official change to the protocol.
Thanks. It's pretty important to avoid any confusion about what is
Hessian 2.1, especially for something like google.
To be perfectly clear, it remains a only a proposal and any
implementation surrounding it is merely trying to add weight to the
proposal.
Right. Proposed changes are fine, just the name has to be something
else to avoid any confusion.
(I'm kind of rushed today, so I don't think I'll be able to respond to
the proposal yet.)
-- Scott
The unfortunate name stemmed from the fact that in my original
patch, I had extended the Hessian2Input and Hessian2Output classes
and called them Hessian21Input and Hessian21Output respectively.
I've changed the title of the article, which was the only public
usage of the term Hessian 2.1: http://hopper.squarespace.com/blog/2008/4/17/proposed-hessian-extension-for-erlang.html
In all other places it is referred to as the proposed extension.
Hope you can accept my apologies,
Ben
On 18 Apr 2008, at 02:58, Scott Ferguson wrote:
On Apr 17, 2008, at 3:12 PM, Ben Hood wrote:
Dear list,
I've created a first formal release of the protocol extension
discussed previously in this thread (Hessian 2.1).
You may not call your proposal Hessian 2.1. Please change the name
now.
-- Scott
The release is a fork of the Erlang implementation for Hessian 2.0.
I've written an article about it:
http://hopper.squarespace.com/blog/2008/4/17/hessian-21-for-erlang.html
The motivation behind this release is to turn a proof-of-concept
into a proper release and to tidy up some aspects of the protocol.
It also intends to demonstrate a workable trade-off between
simplicity and efficiency whilst retaining robustness and
tractability of the protocol.
The release can be mildly regarded as reference implementation of
the proposed extension.
HTH,
ben
On 4 Mar 2008, at 08:30, Ben Hood wrote:
On 3 Mar 2008, at 17:26, Scott Ferguson wrote:
I was just thinking about a variant which uses the current
transmission scope as it is now, but instead of sending the type
information, you send a small hash of the type information.
The receiver would then query the sender for the key that that
created
that hash value.
But adding extra requests complicates the protocol
tremendously. In
particular, a HTTP server doesn't necessarily have the ability to
query the client.
I agree that using HTTP as transport will only allow TCP
connections to be initiated in one direction but that doesn't
necessarily limit the Hessian protocol.
With HTTP for example,
you can use the HTTP response to send a query from the receiver
to the sender, just as you currently use it for the Hessian reply;
you can use a long running TCP connection similar Ajax or Comet
based applications.
You don't necessarily need to bind the Hessian request/response
cycle to the HTTP request/response cycle in a 1:1 fashion.
So it's best to treat Hessian as a single unidirectional stream,
which
also has the advantage that it works for different call or
messaging
styles.
With messaging you have the ability to set up multiple endpoints,
one of which you can use a endpoint for type queries. It is not
difficult to implement an omnidirectional RPC mechanism on top of
MOM. Most MOM APIs will allow to neatly perform selective message
consumption based on a predicate, which in this case you can use
to defer the consumption of instance data until you have
successfully queried the type information in a much cleaner
fashion that using HTTP as a transport.
Furthermore, if you do treat Hessian as a unidirectional stream,
you will have to manage the following issues:
You need maintain coherency of type references across time,
different consumers and potentially across multiple producers. In
this case, the simplicity of the protocol puts a large onus of
the sender, thus making the implementation complicated.
You need to make sure that you send all of your type information
at the beginning of your transmission context. This means you
will have to know when you are starting an interaction with a
particular peer, hence limiting Hessian to specific peer to peer
relationships. How can you guarantee this in a messaging scenario?
What happens if the type information and instance data arrives
out of order?
What happens if a receiver loses a type reference during a long
running interaction? Do they need to cancel the entire
transmission to recover this?
Some of these points are discussed in this article:
http://hopper.squarespace.com/blog/2008/3/3/hessian-type-negotiation-protocol-flow.html
Ben
_______________________________________________
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
_______________________________________________
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
