On Feb 22, 2008, at 3:04 AM, Krügler Daniel wrote:
> Hello,
>
> Since some time we use the Hessian protocol for Java and C++
> successfully, but
> I observed some important key definitions are IMO incompletely
> specified which
> has relevant implications on current implementations, e.g. the
> hessian-3.1.3
> implementation of caucho.com. In the following I restrict on the
> version 1.0.2
> definition of the hessian protocol.
>
> 1) It seems unspecified whether the Hessian map type is supposed to
> accept
> unique keys or possibly multiple equivalent keys (A multi_map in C++
> nomenclature).
> This has consequences during object persistence, because objects in
> typical
> higher programming languages *are* multimap containers in case of
> base-derived
> hierachies. I stumbled across this issue when I tried to read an
> object of type
By definition, a map's keys are unique.
> This essentially means that the hessian protocol *cannot* generally
> persist arbitrary object types - it's has the implicit assumption
> that class
> hierachies don't use replicated member names between their class
> hierachies -
> which is actually a bitter source of hard-to-find bugs during object
> persistence!
That situation can be handled by mapping overriding fields with name
mangling, e.g. "value" for the base field and "value__2" for the
overriding field.
> 2) It also seems unspecified, to which semantic data type the 16 bit
> length specifiers (typically annotated as "b16 b8") belong to. Are
> these signed or
> unsigned types?
Lengths are unsigned. It doesn't make sense for a string to have a
negative length.
-- Scott
> Since there does not exist a fundamental 16 bit type in
> the hessian standard, this question remains unanswered and has also
> some
> implications for existing implementations. The above mentioned caucho
> implementation persists data chunks ('s', 'x', 'b') with size
> 0x8000. This
> number would be too large to be reasonably read as a 16 bit signed
> number
> (which would have a maximum positive value of 0x7fff), and thus
> implies
> an unsigned interpretation. On the other hand - given an unsigned
> interpretation -
> one could reasonably argue that chunk sizes of 0xFFFF should also be
> ok.
>
> This point must be clarified.
>
> Greetings from Bremen,
>
> Daniel Krügler
>
>
> Bruker Daltonik GmbH
> ------------------------------
> Fahrenheitstrasse 4
> 28359 Bremen, Germany
>
> Permoserstrasse 15
> 04318 Leipzig, Germany
>
> Geschäftsführer: Frank Laukien, Ph. D., Gerd Hülso, Sebastian Meyer-
> Plath, Stefan Ruge, Ian Sanders, Ph. D., Dr. Michael Schubert
>
> Sitz der Gesellschaft: Bremen
>
> Handelsregister Amtsgericht Bremen: HRB 8150
>
> www.bdal.de
> ------------------------------------------------------------
> Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht
> verantwortlich für die ordnungsgemäße, vollständige und
> verzögerungsfreie Übertragung der Nachricht. Der Inhalt der E-Mail
> ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief
> oder ein Fax entsprechend bestätigt wird.
> Exclusion from liability: Any liability of Bruker Daltonik GmbH
> referring to the correct, complete and immediate transmission of the
> message shall be excluded. The content of the e-mail including its
> attachments is only legally binding if confirmed by Bruker Daltonik
> GmbH by letter or fax.
>
>
> _______________________________________________
> 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
