Re: Hessian PHP implementation

Hi Scott,

anything new and exciting on the new Hessian release ???. I was
notified today that there is a problem with Hessian and Hibernate (bug
report #2103) which is marked as fixed in 3.0.9.
However that version never made it (as it seems to me). We can't use
Hibernate 3.x until that new Hessian version arrives.

(sorry to push here.... it's probably just because I get pushed)
regards
christian campo

On Mon, 17 Jan 2005 08:58:14 +0100, Christian Campo
<christian.campo@xxx.com> wrote:
> Scott,
> thanks for the schedule.
> Is it possible to contribute to Hessian in any way ? I have some
> improvements, bug fixes, extensions. I assume they would go through
> you and you decide whether they make sense. For example the
> CalendarSerializer/Deserializer I wrote shrinks a Calendar object from
> several hundred bytes to the size of a Date field (below 20 bytes).
>
> What about new features like GZIP ? They save a lot of space again but
> there needs to be a definition in the protocol so that a Hessian-Java
> gzipped request can be executed by Hessian-C or Hessian-PHP
> webservice.
>
> thanks
> christian campo
>
> On Fri, 14 Jan 2005 17:20:11 -0800, Scott Ferguson <ferg@xxx.com> wrote:
> >
> > On Jan 14, 2005, at 11:46 AM, Christian Campo wrote:
> >
> > > Hi Scott,
> > > glad you added your comments to your thread. I couldn't agree more to
> > > most of the things you said in the last mail (using Headers etc.) I
> > > have really no opinion on IDL.
> > >
> > > Maybe there is "finally" :-) a chance that you can say something about
> > > release schedules
> > > for Hessian. I am sure you remember you posted a bug fix that was
> > > promised for Hessian 3.0.10.
> >
> > 3.0.10 was a bit rushed. 3.0.11 is planned for next week, so I'll make
> > sure to release the hessian version then.
> >
> > -- Scott
> >
> > >
> > > The last release (3.0.8) is from June last year. What are you further
> > > plans on releases ??
> > >
> > > The whole thing makes me believe that there is a prepared 3.0.10.
> > > version somewhere or
> > > at least a planned released 3.0.10.
> > >
> > > Are their chances to contribute sourcecode, bug fixes, implementation
> > > to further releases.
> > >
> > > regards
> > > christian
> > >
> > >
> > > On Fri, 14 Jan 2005 11:21:50 -0800, Scott Ferguson <ferg@xxx.com>
> > > wrote:
> > >>
> > >> On Jan 14, 2005, at 10:37 AM, Radu-Adrian Popescu wrote:
> > >>
> > >>> Christian Campo wrote:
> > >>>> Hi Radu-Adrian,
> > >>>> it certainly starts a discussion :-)
> > >>>> Here we probably do not agree fully. One I believe there should be
> > >>>> at
> > >>>> least an option to use a logging package because in the development
> > >>>> stages it makes things so much easier. So you should be able to see
> > >>>> exceptions and stacktraces on the server if you wish and without the
> > >>>> requirement to put webservice specific exception handling into your
> > >>>> business logic. They might not even know that are called as a
> > >>>> webservice.
> > >>>
> > >>> I do remember the original hiccups and the trouble we took to find
> > >>> out
> > >>> what's actually happening when things go wrong, and a lot of things
> > >>> went wrong during implementing both c++ and flash clients. But we got
> > >>> by by dumping raw and hex messages to files, merrily scribbling on
> > >>> pieces of paper and counting bytes with the pencil on the screen.
> > >>
> > >> I think Christian is talking about application-level errors.
> > >> Currently, the Java implementation is not doing a good job of logging
> > >> the application errors. (Partially because of JDK compatibility
> > >> worries, partially because of laziness in the initial implementation.)
> > >>
> > >> Logging the hessian stream itself is a somewhat different issue. It
> > >> would be a good idea to write a pretty-printer so you could at least
> > >> save the stream and look at it.
> > >>>
> > >>>> Third also errors on the client side that happens deep inside are
> > >>>> not
> > >>>> shown in the stacktrace of the HessianRuntimeException. That is
> > >>>> because the HessianRuntimeException has no method getCause(), as I
> > >>>> pointed out earlier in the thread.
> > >>>
> > >>> I'm not sure I read this right: you mean on the client side as in
> > >>> you're in the client, call on server and an error pops up and you
> > >>> can't tell where it originates from / the actual cause ? If that's so
> > >>> then I guess it does need improvement.
> > >>
> > >> These are mostly issues with the Java implementation.
> > >>>> GZIP encoding all the time because it eats CPU time. So say your
> > >>>> client program wants the tell the server to use GZIP when it has
> > >>>> mobile (GPRS) connection and not use GZIP when its on the LAN. An
> > >>>> Accept-encoding header is the way to go and even though it requires
> > >>>
> > >>> Like I said, the Accept-Encoding header seems to be best suited for
> > >>> this, at least from a formal point of view.
> > >>> If this be the way it's going to be done, I strongly suggest defining
> > >>> some domain specific encodings, for instance:
> > >>> hessian_raw, hessian_gzip, hessian_bzip, hessian_flash,
> > >>> hessian_whatnot.
> > >>> I'm not terribly sure about this, but it may avoid problems in
> > >>> set-ups
> > >>> such as using an Apache front-end with
> > >>> mod_proxy/mod_proxy_http/ProxyPassReverse and mod_[gzip|deflate]. It
> > >>> may also allow for less-than-capable clients such as Flash to use
> > >>> Accept-Encoding: gzip, deflate to send/receive using compression
> > >>> implemented by the standard HTTP stack in any web server.
> > >>
> > >> Actually, the Accept-Encoding would work just fine, and letting Apache
> > >> (or Resin's GzipFilter) do the compression should work. I don't think
> > >> there's any need for "hessian_*" values.
> > >>
> > >>> Here's a thought: how about adding two bytes after the call that
> > >>> serves as a sort of an accept-encoding or "features" tag ?
> > >>> c 0x01 0x00 features
> > >>> features ::= b16 b8
> > >>> Then define FEATURE_NONE = 0, FEATURE_GZIP = 2, FEATURE_SIGN_MD5 = 4
> > >>> and so on.
> > >>> This would be simpler than using hessian's header feature, as an user
> > >>> of the stream does not need to understand the whole serialisation in
> > >>> order to detect the features of the stream.
> > >>
> > >> I think those sorts of flags would belong in an envelope, if that was
> > >> necessary.
> > >>
> > >> E 0x01 0x00 features headers hessian-content
> > >>
> > >> The call/reply itself shouldn't know or care how it's
> > >> encoded/compresses/digested.
> > >>
> > >>>
> > >>> It just hit me, using HTTP headers is an really bad idea if you want
> > >>> to use Hessian over plain sockets and skip the whole HTTP stuff.
> > >>> Right
> > >>> ?
> > >>
> > >> Yes, but a plain socket protocol would probably add some kind of
> > >> flow-control or encapsulation protocol over the main Hessian calls.
> > >>
> > >> You could also have the rule that if a client request was gzipped, the
> > >> response should be gzipped as well. Logically, that's an
> > >> encapsulation, even though it's just determined by looking at the
> > >> first
> > >> byte.
> > >>
> > >>> Also on the binary xml / fast web services, I've seen them getting a
> > >>> hell of a beating for that ASN.1 choice. I may be out of my depth
> > >>> here
> > >>> a bit, but why not use CDR (of CORBA) or XDR (of Sun's RPC) ?
> > >>
> > >> IIOP is horribly complex from an implementation perspective. The
> > >> basic
> > >> byte/integer/double is fine, but the encoding of strings and objects
> > >> is
> > >> ugly.
> > >>
> > >> XDR would be fine, but I don't know if it can handle arbitrary (i.e.
> > >> non-predefined by IDL) objects.
> > >>
> > >> I haven't really looked into it as much as I probably should. They
> > >> may
> > >> just be trying to solve different problems.
> > >>
> > >>> These are well established serialisation formats and may allow for
> > >>> better integration in the enterprise.
> > >>
> > >>> At any rate, hessian's serialisation is pretty straight-forward and
> > >>> unambiguous, and it feels neat (as opposed to bloated).
> > >>
> > >> Yep. An IDL-based protocol could be a bit more compact (I think the
> > >> ICE guys have created a straightforward IDL-based protocol), but
> > >> Hessian is pretty compact for a self-describing protocol.
> > >>
> > >> -- Scott
> > >>
> > >>>
> > >>> --
> > >>> Radu-Adrian Popescu
> > >>> CSA, DBA, Developer
> > >>> Aldrapay MD
> > >>> Aldratech Ltd.
> > >>> +40213212243
> > >>
> > >>
> > >
> > >
> > > --
> > > christian campo (gmail.com)
> >
> >
>
>
> --
> christian campo (gmail.com)
>

-- 
christian campo (gmail.com)