Experimental Physics and
Industrial Control System

[email protected] · Tue, 14 Feb 95 10:07:50 -0600

>[email protected] writes:
>I think the largest part of the decrease comes from not reporting
>fields that are still the default value. Is that correct?

Yes this is true.

>someone whose name escapes me wrote:
>I think the original proposal was to ASCIIize default.dctsdr, which is where
>the default values are transmitted aren't they? This would send the size up
>from 350K bytes to something over 1Mb. Still no problem for you?

Still no problem to me... especially since I doubt that we will end up
with that large a size increase.  Even so, it is only one copy of the
default values for each record TYPE.  The reduction is size of the 
record instances should compensate for it in reasonably sized
databases... and the small ones are small enough to survive some
increase for the sake of simplicity anyway.

>[email protected] writes:
>The one "fly in the ointment", so to speak, is the lack of tools for "pre-
>init-time" verification of the .db files.  This is the one _very_ useful
>function of dct which seems to have no replacement.

This is not accurate.  GDCT uses the ASCII files directly, and it has
the same engine as DCT.  So it is assured that enumerators and value
ranges are verified when the database is created.

>I'd like to see the ascii database load function (or a new one) be able
>to recognize and decompress 'zip' formatted ascii database files.  This could
>provide the advantages of binary loading speed by cutting down on the net
>traffic, and ascii compatibility since plenty of tools for handling 'zip'
>files are available on hosts.  Database loading takes longer than we'd like.

I like the idea, but I am not sure that zipping the database will save
much load time.  I'd like to see some numbers on that one.

--John

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System