Re: Hessian PHP implementation

On Jan 28, 2005, at 4:56 AM, Christian Campo wrote:

> 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)

You can always use the Resin snapshots (resin.jar) to test Hessian bug
fixes.

We're working on the next releases for the next week or two, but this
part of the release process is pretty slow, getting the regressions all
to pass and working through the different configurations and stress
testing.

-- Scott

> 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)
Received on Fri 28 Jan 2005 08:50:06 -0800