Re: Rep clause problems, was Re: S'Write and How To Count Bytes

[Marin David Condic <mcondic.nospam@acm.org>]

Simon Wright wrote:

> I thought you had predefined message formats, which have to be
> understood by code over which you have little control. So this format
> will specify field locations and (if you're lucky) endianness. What it
> certainly won't contain is a space for an Ada tag.
>

In the case I'm working on now, I do have a predefined message catalog.
Presuming that you do something with representation clauses on tagged
records rather than using a stream, you have some work to do. The tag in
the record, you have to get rid of in an implementation dependent manner.
Fortunately, while there may be hundreds of ways of implementing tagged
records, only one of them doesn't look silly: Put an integer at the front
of the base record type. You have to figure out the number of bits and use
that for your rep clause anyway, so its pretty easy to start your overlay
by stepping over the tag. It would help if Ada provided attributes to help
you out here - either by guaranteeing the size and location of the tag or
by inventing something like: Rec_Type'Starting_Point_Of_All_Non_Tag_Stuff.
The problem is you just can't seem to get control of the representation of
tagged types even if you can get around the tag with minimal fuss.


>
> Seems to me you need packages to handle the wire formats and packages
> to handle your tagged types; and when it comes to send a message you
> might use streams in your tagged type package, but the implementation
> of the 'Output etc will need to use the appropriate wire format
> package. And the input wire format package will create and return some
> object(s) in your tagged world.
>

That's sort of basically where I'm going for this case. I've got the
tagged record where I can use 'Read and 'Write to get it in the format for
the hose or get it back when I need it. Coming in, you have to do your own
dispatching when looking at the raw bytes so that you can create the
record type you need, but there's no way around that. If I don't get
exactly the format I want by the default 'Read and 'Write, for the
elementary types, I can replace them with something that will.

>
> I'm assuming that your tagged types are in your application domain,
> not the comms domain? if the former, I've found that messages rarely
> map at all to application classes; if the latter, the message set
> rarely maps straightforwardly to any sort of inheritance tree.

Not sure what you mean here. Let me see if I get close. All my messages
have a predefined message header that contains things like a sync pattern,
number of bytes, message identifier, yada, yada, yada. Then all the
"application specific" data content follows this message header. The tree
is very flat - although I suppose one day there may be some levels to it.
Mostly, you need to pull the bytes from the wire, figure out which of
maybe fifty or more messages is coming in, pull that message off the wire
and let the application have at it. (Naturally, theres a lot of error
checking, recovery, etc. that goes in all this too, but the process is
basically that.)

What I'd like is not necessarily some deep inheritance tree kind of thing.
I just want to be able to treat messages as what they are - a class. All
messages have some things in common - they all have a header, they all
translate into a stream of raw bytes of some determinable length, they all
transmit and receive up and down the same wire with the same hardware,
etc. It would be nice to support all the sending and receiving and such
from a class-wide set of operations and allow dispatching to handle the
specific cases.

MDC




--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================