Re: Hessian PHP implementation

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)