Guy Harris wrote:
>
> On Wed, Jan 24, 2001 at 04:33:19PM -0600, Frank Singleton wrote:
> > Initially I was going to use packet-giop.[ch]
> > as I have proposed earlier, but it would be nice
> > to bolt it into the ethereal FT_xx types
>
> Do types represent the type of the underlying data (in which case
> FT_CDR_LONG is just another name for FT_UINT32), or the way it's
> represented in packets?
Hi,
Wow !! Lots of points of view out there.
Thats good ,right !
>From my investigation into CDR mapping onto GIOP,
then (at least for primitive CDR types), there is
2 main issues.
1. Alignment of types to boundaries . This easily
handled by the get_CDR_xxx routines that are
being added to packet-giop.[ch] and consistent with
my earlier proposal in december.
2. The data types introduced by CDR.This can also
be handled by "accessor methods" get_CDR_xxx
and subsequently we can populate the ethereal
tree using the basic types already present (with
a little footwork).
I was testing the waters for such things as FT_UINT64,
FT_LONG_DOUBLE, etc that perhaps would be useful for
both CORBA folks and the group.
FT_CDR_LONG could indeed me handled by FT_UINT32, and
was not a good example to pull from the bag :-(
But comments on the other 2 would be welcome.
Judging from the comments so far, I think I will
stick with get_CDR_XXX stuff in giop :-)
Cheers / Frank..
--
EUS/SV/Z Frank Singleton ASO Americas BSS
Office : +1 972 583 3251 ECN 800 33251
Pager : +1 800 651 1184 Mobile : +1 214 228 0874
Amateur Radio: VK3FCS/KM5WS Email : frank.singleton@xxxxxxxxxxxx
Hardware: HP Omnibook 4150 running Redhat Linux 6.2 (2.2.16 kernel).
