Re: A standard package for config files is needed

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205310825.868fe4a@posting.google.com...
>
> No its not. There's nothing in the Ada standard that says the data
> written out to streams has to be portable, or even what its format is
> at all. I think the order subobjects of compound structures get
> written out is specified, but that's about it. Configuration files
> generated via this method will not work with another compiler, will
> probably not work on another platform, and are not even guaranteed to
> work with *the same* compiler after an upgrade (unless your vendor
> cares to give you that guarantee).
>
Sorry. I didn't mean that the *file* would be portable. I meant that the
*code* would be portable. It would use no features outside of the standard
Ada language. (Unlike, say connecting to the Win32API to get all the
information from the registry.)

I just don't see file portability being that big an issue. Certainly not any
more important than the fact that there is no guaranteed portability of
anything you create with any of the other I/O packages.

> Also realise that for many programs, developing their own tools to
> allow users to change the settings would be a real pain. Not every
> program is an interactive GUI app.
>
Sure, but if the protocol is for the app to establish default values on
startup for anything that is missing and then to save values as user's
change things in the app, it wouldn't be a big deal. This isn't the sort of
thing to use for a massive database - just a relative handful of things that
a program needs to remember between executions.


> With a text file you can lay all the options out there for the user,
> and even add comments to explain *why* the settings were put where
> they currently are. You can't easily do that with a program
> (particuarly an embeded or real-time app with no user interface).
>
But in an embedded, realtime app, I seldom have Text_IO anyway. :-) Here,
I'd be better off with a Stream that I could somehow write into NVRAM,
rather than rely on a file system that maybe doesn't exist.

I'm suggesting that a Stream oriented load/store would get the whole thing
*started* and then these load/store operations could be overriden by child
packages that might support a whole range of different options. Build the
AdaINIRegistry as a tagged record with the right methods that hide the
mechanism for storage and it is easily changed for different situations.

As a matter of fact, the OO strategy would give you the natural means of
doing default initialization of the registry because you could derive from
the root and the "Load" checks to see that something is present for the
app-dependent entries. If not, it creates them. Hmmm.....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com