Re: Hessian PHP implementation

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)
Received on Fri 14 Jan 2005 17:20:11 -0800