A standard package for config files is needed

A standard package for config files is needed

[Preben Randhol]

On the GtkAda list there has been some discussion on making a standard
package for reading/writing configuration files. As most programs need
this it would be very nice with a small, platform independant, robust
but easy to use package.

Of course one can use XML for something like this, but in most
applications this would be an overkill. Besides a program shouldn't have to be
tie in with XMLAda just because of the configuration files. This package
should be nice for small applications made by student, hobbyists or
professionals.

So I hope now to kick off a discussion around this. 

We have been discussing a bit about Window registry versus .ini files,
and have more or less agreed that the latter is the better. The reason
is that .ini files are: 

   * Platform independant (can use the exact same routines on Unix)
   * Easier to backup
   * Easier to have more than one version of

So what it then boils down to is for the user to supply the package with
the propper filename depending on if she/he is using Windows, Unix or
other.

If Windows registry is needed it would best be developed as a seperate
package I think, as this would not be useful on other platforms.

Then there is the issue of the layout of the config file. Either one
could do:

[Program]
Name=SuperDuperApp
Version=1.0

[Directory]
Help=/usr/doc/SuperDuperApp/
Graphics=/usr/share/pixmaps/SuperDuperApp/

etc...

or

Program.Name=SuperDuperApp
Program.Version=1.0
Directory.Help=/usr/doc/SuperDuperApp/
Directory.Graphics=/usr/share/pixmaps/SuperDuperApp

etc...

So if somebody would like to share ideas, suggestions or code it would
be very nice.

I think this is a package that should be kept as simple as possible and
easy to use and robust.

Preben Randhol

Re: A standard package for config files is needed

[Martin Dowie]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaf6onp.lpu.randhol+abuse@kiuk0152.chembio.ntnu.no...
> On the GtkAda list there has been some discussion on making a standard
[snip]

"Localization" would be a good one to address to, IMHO

Re: A standard package for config files is needed

[Preben Randhol]

On Tue, 28 May 2002 13:09:01 +0100, Martin Dowie wrote:
> "Localization" would be a good one to address to, IMHO

What do you mean?

Preben

Re: A standard package for config files is needed

[Darren New]

Preben Randhol wrote:
> Of course one can use XML for something like this, but in most
> applications this would be an overkill. 

XML is generally overkill anywhere you don't have blocks of text (i.e.,
CDATA) as part of your data structures.

> We have been discussing a bit about Window registry versus .ini files,
> and have more or less agreed that the latter is the better. The reason
> is that .ini files are:
> 
>    * Platform independant (can use the exact same routines on Unix)
>    * Easier to backup
>    * Easier to have more than one version of

Be aware that using the registry has some benefits also, including (for
example) roaming profiles, where you get "your" registry regardless of which
computer you log into, notification of changes by other processes, etc.

Also, be aware that .ini files and the registry are in many senses
API-compatible.

Hence, I'd suggest perhaps considering whether it could be designed in such
a way that only the "open" routine knows whether it's the registry or a
file. (Not that you need to implement both immediately.)
 
> So what it then boils down to is for the user to supply the package with
> the propper filename depending on if she/he is using Windows, Unix or
> other.

And here I would suggest perhaps "registry subkey" would be another
appropriate bit to supply. I.e., if you give a file name, it stores it in an
.ini file, and if you give a registry subkey, it stores it in a registry
subkey.
 
> So if somebody would like to share ideas, suggestions or code it would
> be very nice.

Why not examine the .ini and registry interfaces for Windows and see if they
translate cleanly into something you could do in Ada?
 
Are you considering putting arbitrary streams into the configuration files,
or only readable text that would have to get parsed in and out manually?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[achrist]

Darren New wrote:
> 
> Preben Randhol wrote:
> > Of course one can use XML for something like this, but in most
> > applications this would be an overkill.
> 
> XML is generally overkill anywhere you don't have blocks of text (i.e.,
> CDATA) as part of your data structures.
> 
> > We have been discussing a bit about Window registry versus .ini files,
> > and have more or less agreed that the latter is the better. The reason
> > is that .ini files are:
> >
> >    * Platform independant (can use the exact same routines on Unix)
> >    * Easier to backup
> >    * Easier to have more than one version of
> 
> Be aware that using the registry has some benefits also, including (for
> example) roaming profiles, where you get "your" registry regardless of which
> computer you log into, notification of changes by other processes, etc.
> 
> Also, be aware that .ini files and the registry are in many senses
> API-compatible.
> 
> Hence, I'd suggest perhaps considering whether it could be designed in such
> a way that only the "open" routine knows whether it's the registry or a
> file. (Not that you need to implement both immediately.)
> 

There is some chance for a big mess here, thanks to progress that MS
has already made in this direction.  There is support for ini files
in the Windows api, and MS has at some time said that it might migrate
the ini files into the registry without letting the application using
the Windows API to access the ini parameters know.  So, not even the
program opening the ini files knows for sure.  Reading and writing ini 
files as files already breaks MS's API.  I've not hit a case where it
breaks MS's actual implementation, but it might.  

The possible downsides of all this are stunning, but the upside is that
because the registry is like a database, the programmer using the
registry
does not so much worry about what happens if multiple programs accessing
and updating the same settings might be running simultaneously.

Al

Re: A standard package for config files is needed

[Darren New]

achrist@easystreet.com wrote:
> There is some chance for a big mess here, thanks to progress that MS
> has already made in this direction.  There is support for ini files
> in the Windows api, and MS has at some time said that it might migrate
> the ini files into the registry without letting the application using
> the Windows API to access the ini parameters know. 

I think that already works, if you go thru the right INI APIs. Of course, if
you use open/read/write/close it won't work.

> The possible downsides of all this are stunning, but the upside is that
> because the registry is like a database, the programmer using the
> registry
> does not so much worry about what happens if multiple programs accessing
> and updating the same settings might be running simultaneously.

Yes. And the other upside is that the OS can *do* things with that info,
*because* it knows it's an INI file, that it can't do with plain old files.
Like move them between computers when you log in, and let different programs
update different parts on different machines and then merge the results
together when both programs terminate, and so on.

Was just a thought, really. My intention was to say that the API would work
better as something like "here's a key and a value, remember it" than it
would "output a [blah] header, output a key, output a value" kind of thing,
implying a sequential file as an underlying implementation. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Marin David Condic]

Here's just a thought: The Grace components has the aim of creating a Map
component. Assuming you can get serialization out of a Map component via
'Read, 'Write, 'Input & 'Output, it would be the natural data structure on
which to build an INI file. If not Grace, perhaps some other package would
be useful to build on, but I'd imagine a spec that was similar, just
narrowed down to the needs of an INI file. With a Map, you've got everything
you need to store & query attribute/value pairs, eh? (Editing by hand might
be a bit of a problem. But why couldn't an extension include some kind of
editor? It might even evolve into its own form of registry?)

Assuming we get a Grace component to do this, it might even make a nice
extension to the Grace library - a descendent of Maps that handles
initialization work?

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


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaf6onp.lpu.randhol+abuse@kiuk0152.chembio.ntnu.no...
> On the GtkAda list there has been some discussion on making a standard
> package for reading/writing configuration files. As most programs need
> this it would be very nice with a small, platform independant, robust
> but easy to use package.
>

Re: A standard package for config files is needed

[Mark Biggar]

Darren New wrote:
 
> Be aware that using the registry has some benefits also, including (for
> example) roaming profiles, where you get "your" registry regardless of which
> computer you log into, notification of changes by other processes, etc.
> 
> Also, be aware that .ini files and the registry are in many senses
> API-compatible.
> 
> Hence, I'd suggest perhaps considering whether it could be designed in such
> a way that only the "open" routine knows whether it's the registry or a
> file. (Not that you need to implement both immediately.)

I'm not sure that the benefits of the Registry out way the problems.
The Registry seems a major step backward in term of system coupling.
A program that corrupts the Registry can effect not only itself
but the operation of almost any other program on the system.
A program that corrupts its .ini file usually only impacts its
own operation.  From a security analysis point of view the
Registry appears to be the biggest flaw in the whole windows/NT
architecture.


--
Mark Biggar
mark.a.biggar@attbi.com

Re: A standard package for config files is needed

[SteveD]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaf6onp.lpu.randhol+abuse@kiuk0152.chembio.ntnu.no...
> On the GtkAda list there has been some discussion on making a standard
> package for reading/writing configuration files. As most programs need
> this it would be very nice with a small, platform independant, robust
> but easy to use package.
>
> Of course one can use XML for something like this, but in most
> applications this would be an overkill. Besides a program shouldn't have
to be
> tie in with XMLAda just because of the configuration files. This package
> should be nice for small applications made by student, hobbyists or
> professionals.
>

Gee. I thought this was just the kind of thing that XMLAda was good for.

A few lines of code to read the configuration file (XML) followed by a few
lines of code to access the data.

Then if you decide you want to do something more fancy with configuration
there is little additional cost.

SteveD

>
> I think this is a package that should be kept as simple as possible and
> easy to use and robust.
>
> Preben Randhol

Re: A standard package for config files is needed

[Hyman Rosen]

Mark Biggar wrote:
> I'm not sure that the benefits of the Registry out way the problems.
> The Registry seems a major step backward in term of system coupling.
> A program that corrupts the Registry can effect not only itself
> but the operation of almost any other program on the system.

I've seen this nonsensical argument too many times to count.
One could say as easily that a program which corrupts the
filesystem can affect any program in the system, so it is
best not to use files.

The registry API calls for setting and getting your own
parameters are perfectly safe, and only affect designated
items. There is no chance of corrupting the registry through
their use. This anti-registry sentiment is pure FUD.

Re: A standard package for config files is needed

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> The registry API calls for setting and getting your own
> parameters are perfectly safe, and only affect designated
> items. There is no chance of corrupting the registry through
> their use. This anti-registry sentiment is pure FUD.

I have one case were it does happen. I bought the Easy CD Creator 5.0 platinum
version. When installed on XP it has corrupted the Explorer icons. I had to
tweak the registry to get back icons for my removable drives... FUD certainly
not, but for sure it is quite rare.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: A standard package for config files is needed

[Volkert]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnaf6onp.lpu.randhol+abuse@kiuk0152.chembio.ntnu.no>...

> 
> So I hope now to kick off a discussion around this. 

The Java Property class is simple and easy to use! The Properties
can be stored as an ASCI File, which is a  List of (Key,Value) pairs.
The Ada Version should be a bit more powerfull. e.g store
triples of (Scope,Key,Value), may be in be form you described
above: Scope.Key=Value

>Program.Name=SuperDuperApp
>Program.Version=1.0
>Directory.Help=/usr/doc/SuperDuperApp/
>Directory.Graphics=/usr/share/pixmaps/SuperDuperApp,

The Java Interfaces may be a starting point!

String getProperty(String key)
Searches for the property with the specified key in this property list.
     
String getProperty(String key, String defaultValue) 
Searches for the property with the specified key in this property list.
        
void list(PrintStream out) 
Prints this property list out to the specified output stream.
    
void list(PrintWriter out) 
Prints this property list out to the specified output stream.

void
load(InputStream inStream) 
Reads a property list (key and element pairs) from the input stream.

Enumeration propertyNames() 
Returns an enumeration of all the keys in this property list, 
including the keys in the default property list.

Object setProperty(String key, String value) 


Volkert

Re: A standard package for config files is needed

[Preben Randhol]

On Tue, 28 May 2002 16:33:11 GMT, Darren New wrote:
> Preben Randhol wrote:
> 
> Be aware that using the registry has some benefits also, including
> (for example) roaming profiles, where you get "your" registry
> regardless of which computer you log into, notification of changes by
> other processes, etc.
> 
> Also, be aware that .ini files and the registry are in many senses
> API-compatible.

But we don't want to use any Windows API for reading .ini files. We
don't need to. And if one wants to use the registry then one should put
this in another pacakge as it would not be needed on Linux/Unix/Mac
etc...

-- 
"Jeg tror nordmenn har glemt hvordan de tilbreder fisk. De er mest
 opptatt av firkantet fisk."
  --  Kristian Kristiansen, yrkesfisker, aftenposten.no 19/04/02

Re: A standard package for config files is needed

[Preben Randhol]

On Tue, 28 May 2002 16:44:09 -0400, Marin David Condic wrote:
> Here's just a thought: The Grace components has the aim of creating a
> Map component. Assuming you can get serialization out of a Map
> component via 'Read, 'Write, 'Input & 'Output, it would be the natural
> data structure on which to build an INI file. If not Grace, perhaps
> some other package would be useful to build on, but I'd imagine a spec
> that was similar, just narrowed down to the needs of an INI file. With
> a Map, you've got everything you need to store & query attribute/value
> pairs, eh? (Editing by hand might be a bit of a problem. But why
> couldn't an extension include some kind of editor? It might even
> evolve into its own form of registry?)

The user should be allowed to edit the config files by hand yes.

> Assuming we get a Grace component to do this, it might even make a
> nice extension to the Grace library - a descendent of Maps that
> handles initialization work?

Yes it would be nice to have this in Grace, but at the moment it would
be nice to develop something that can be used until grace is getting
along.

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Wed, 29 May 2002 02:18:28 GMT, SteveD wrote:

> Gee. I thought this was just the kind of thing that XMLAda was good
> for.
> 
> A few lines of code to read the configuration file (XML) followed by a
> few lines of code to access the data.
> 
> Then if you decide you want to do something more fancy with
> configuration there is little additional cost.

The problems with XML is:

   1) Hard to handedit/read for the user
   2) Have applications depend on XML/Ada for only the config files
      seams bloat.
   3) Would need a DTD for each the config file

Preben

Re: A standard package for config files is needed

[SteveD]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaf9djb.u9.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Wed, 29 May 2002 02:18:28 GMT, SteveD wrote:
>
> > Gee. I thought this was just the kind of thing that XMLAda was good
> > for.
> >
> > A few lines of code to read the configuration file (XML) followed by a
> > few lines of code to access the data.
> >
> > Then if you decide you want to do something more fancy with
> > configuration there is little additional cost.
>
> The problems with XML is:
>
>    1) Hard to handedit/read for the user

Here is a simple XML file, hard to edit... maybe:

<config
left="30"
right="50"
up="20"
down="60"
/>

Here is the bloated code it takes to read the values (tested):
WITH Tree_Readers; USE Tree_Readers;
WITH Ada.Text_Io;

procedure Config_Demo is

    inFile      : Input_Sources.File.File_Input;
    tree_reader : Tree_Readers.Tree_Reader;
    doc         : DOM.Core.Document;
    element     : DOM.Core.Element;
    left  : Integer;
    right : Integer;
    up    : Integer;
    down  : Integer;

begin
  Input_Sources.File.Open( "config.txt", inFile );
  Set_Feature( tree_reader, Validation_Feature, FALSE);
  Parse( tree_reader, inFile );
  doc := Get_Tree( tree_reader );
  Input_Sources.File.Close( InFile );
  element := Dom.Core.Documents.Get_Element( Doc );
  left := Integer'Value( Dom.Core.Elements.Get_Attribute( element,
"left" ) );
  right := Integer'Value( Dom.Core.Elements.Get_Attribute( element,
"right" ) );
  up := Integer'Value( Dom.Core.Elements.Get_Attribute( element, "up" ) );
  down := Integer'Value( Dom.Core.Elements.Get_Attribute( element,
"down" ) );
  Ada.Text_Io.Put_Line( "Left: " & Integer'IMAGE( left ) );
  Ada.Text_Io.Put_Line( "Right: " & Integer'IMAGE( right ) );
  Ada.Text_Io.Put_Line( "Up: " & Integer'IMAGE( up ) );
  Ada.Text_Io.Put_Line( "DOwn: " & Integer'IMAGE( down ) );
end Config_Demo;

If all you want is value attribute pairs, it would certainly be easy to put
this inside a wrapper package.


>    2) Have applications depend on XML/Ada for only the config files
>       seams bloat.

Perhaps.  But re-inventing the wheel seems a crying shame.

>    3) Would need a DTD for each the config file

XML does not require a DTD.  You may give one if you want, but they are
definitely not required.

>
> Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Wed, 29 May 2002 12:57:23 GMT, SteveD wrote:
><config
> left="30"
> right="50"
> up="20"
> down="60"
> />

Not a very nice XML I might say. Besides this is far to simple.

Preben

Re: A standard package for config files is needed

[SteveD]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnaf9khh.2g4.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Wed, 29 May 2002 12:57:23 GMT, SteveD wrote:
> ><config
> > left="30"
> > right="50"
> > up="20"
> > down="60"
> > />
>
> Not a very nice XML I might say. Besides this is far to simple.

Wait a minute.  I thought you were looking for a simple way handling program
configurations.  Now you think XML is too simple?

IMHO one of the nice things about XML is you can make it as simple or as
complex as you want.  If you want to have a configuration file that is a
simple set of name value pairs, XML fits.  If you want to have a
configuration file that describes trees of data, XML fits.  If you want to
have the parser validate the XML using a DTD so your code doesn't have to,
XML fits.

SteveD

>
> Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Wed, 29 May 2002 13:52:42 GMT, SteveD wrote:
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrnaf9khh.2g4.randhol+abuse@kiuk0156.chembio.ntnu.no...
>> On Wed, 29 May 2002 12:57:23 GMT, SteveD wrote:
>> ><config
>> > left="30"
>> > right="50"
>> > up="20"
>> > down="60"
>> > />
>>
>> Not a very nice XML I might say. Besides this is far to simple.
> 
> Wait a minute.  I thought you were looking for a simple way handling program
> configurations.  Now you think XML is too simple?

No your example.

The commercial world needs Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Pascal Obry et al.

Roxio supplied the equivalent of DirectCD for Windows XP. DirectCD is a
simple utility for writing to CDROMs and CDRWs. Roxio's Windows XP
utility has some interesting features: 1) it writes to my CDRW slightly
faster than an XP does to a floppy disc and 2) control C does not work
for copying a file, 3) if does not generate appropriate exceptions if
your CDRW BIOS is not functioning correctly. An Ada program to manage
writing to CDs should have the distinct commercial advantage of working.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Pascal Obry
Sent: Wednesday, May 29, 2002 12:18 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed


Hyman Rosen <hyrosen@mail.com> writes:

> The registry API calls for setting and getting your own
> parameters are perfectly safe, and only affect designated
> items. There is no chance of corrupting the registry through
> their use. This anti-registry sentiment is pure FUD.

I have one case were it does happen. I bought the Easy CD Creator 5.0
platinum
version. When installed on XP it has corrupted the Explorer icons. I had
to
tweak the registry to get back icons for my removable drives... FUD
certainly
not, but for sure it is quite rare.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Preben et al.

Firstly,"3) Would need a DTD for each the config file." No! Since XML
schemas can almost have a one to one correspondence with an Ada package,
the Ada community benefits by the use of Schemas.

XML has two advantages over Ada. 1) More users and 2) eventually more
tools. It has the disadvantage, that except for XSL Fo, XML lacks
subprograms. Parenthetically, XML would benefit from the services of Ada
language lawyers.

As for bloat, if readability requires bloat, then it is by far the
lesser of two evils.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Preben Randhol
Sent: Wednesday, May 29, 2002 4:07 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed

On Wed, 29 May 2002 02:18:28 GMT, SteveD wrote:

> Gee. I thought this was just the kind of thing that XMLAda was good
> for.
> 
> A few lines of code to read the configuration file (XML) followed by a
> few lines of code to access the data.
> 
> Then if you decide you want to do something more fancy with
> configuration there is little additional cost.

The problems with XML is:

   1) Hard to handedit/read for the user
   2) Have applications depend on XML/Ada for only the config files
      seams bloat.
   3) Would need a DTD for each the config file

Preben

RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Volkert et al.

Aonix had an Ada compiler for DOS that used a command language called
AdaWorld. I would hazard that an Ada J code compiler could have packages
with the same functionality. It might be a little verbose. However, this
might be useful for those of us who are Ada users rather than providers.


-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Volkert
Sent: Wednesday, May 29, 2002 12:23 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed

Preben Randhol <randhol+abuse@pvv.org> wrote in message
news:<slrnaf6onp.lpu.randhol+abuse@kiuk0152.chembio.ntnu.no>...

> 
> So I hope now to kick off a discussion around this. 

The Java Property class is simple and easy to use! The Properties
can be stored as an ASCI File, which is a  List of (Key,Value) pairs.
The Ada Version should be a bit more powerfull. e.g store
triples of (Scope,Key,Value), may be in be form you described
above: Scope.Key=Value

>Program.Name=SuperDuperApp
>Program.Version=1.0
>Directory.Help=/usr/doc/SuperDuperApp/
>Directory.Graphics=/usr/share/pixmaps/SuperDuperApp,

The Java Interfaces may be a starting point!

String getProperty(String key)
Searches for the property with the specified key in this property list.
     
String getProperty(String key, String defaultValue) 
Searches for the property with the specified key in this property list.
        
void list(PrintStream out) 
Prints this property list out to the specified output stream.
    
void list(PrintWriter out) 
Prints this property list out to the specified output stream.

void
load(InputStream inStream) 
Reads a property list (key and element pairs) from the input stream.

Enumeration propertyNames() 
Returns an enumeration of all the keys in this property list, 
including the keys in the default property list.

Object setProperty(String key, String value) 


Volkert

Re: A standard package for config files is needed

[Martin Dowie]

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:mailman.1022683322.20042.comp.lang.ada@ada.eu.org...
[snip]
> As for bloat, if readability requires bloat, then it is by far the
> lesser of two evils.

Buzzzzzzz, sorry not on the platform I'm developing for... :-(

Re: A standard package for config files is needed

[Preben Randhol]

On Wed, 29 May 2002 07:41:20 -0700, Robert C. Leif wrote:
> 
> As for bloat, if readability requires bloat, then it is by far the
> lesser of two evils.

But XML is les readable.

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Wed, 29 May 2002 07:41:20 -0700, Robert C. Leif wrote:

> XML has two advantages over Ada. 1) More users and 2) eventually more
> tools. It has the disadvantage, that except for XSL Fo, XML lacks
> subprograms. Parenthetically, XML would benefit from the services of
> Ada language lawyers.

Just to clarify, we are talking about config files not the file format
of files stored by a program.

Preben

Re: A standard package for config files is needed

[Darren New]

Preben Randhol wrote:
> But we don't want to use any Windows API for reading .ini files.

Correct. My point is that since they're API compatible under Windows, one
should strive to make them API compatible in the Ada implementation, where
possible.

> We
> don't need to. And if one wants to use the registry then one should put
> this in another pacakge as it would not be needed on Linux/Unix/Mac
> etc...

Right. And it should have (for most/all opperations that the .ini package
supports) a compatible syntax with the .ini package, right? I mean, why
introduce gratuitous differences between two packages designed to do
essentially the same thing?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: The commercial world needs Ada was RE: A standard package for config files is needed

[Darren New]

"Robert C. Leif" wrote:
> 1) it writes to my CDRW slightly
> faster than an XP does to a floppy disc and 2) control C does not work
> for copying a file, 3) if does not generate appropriate exceptions if
> your CDRW BIOS is not functioning correctly. An Ada program to manage
> writing to CDs should have the distinct commercial advantage of working.

What makes you think any of these flaws are specifically caused by the
choice of language in which anything is programmed?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Darren New]

SteveD wrote:
> 
> "Preben Randhol" <randhol+abuse@pvv.org> wrote in message
> news:slrnaf9khh.2g4.randhol+abuse@kiuk0156.chembio.ntnu.no...
> > On Wed, 29 May 2002 12:57:23 GMT, SteveD wrote:
> > ><config
> > > left="30"
> > > right="50"
> > > up="20"
> > > down="60"
> > > />
> >
> > Not a very nice XML I might say. Besides this is far to simple.
> 
> Wait a minute.  I thought you were looking for a simple way handling program
> configurations.  Now you think XML is too simple?

I suspect he means to ask how the XML would look for the following .ini
file:

name=Darren "The Dude" New
relational=<=
marriage=Wen's Husband
this.city=San Diego

and so on.

There are advantages to using XML for this. Ease of hand-editting is not one
of them.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Hyman Rosen]

Pascal Obry wrote:
> I have one case were it does happen. I bought the Easy CD Creator 5.0 platinum
> version. When installed on XP it has corrupted the Explorer icons. I had to
> tweak the registry to get back icons for my removable drives... FUD certainly
> not, but for sure it is quite rare.

This is clearly a case where the software is deliberately going
out of its way to touch registry entries that don't belong to it.
Don't do that. But it's irrelevant to the case of storing your
own private configuration parameters.

Re: A standard package for config files is needed

[Chad R. Meiners]

"Preben Randhol" <randhol+abuse@pvv.org> wrote in message > So I hope now to
kick off a discussion around this.

> We have been discussing a bit about Window registry versus .ini files,
> and have more or less agreed that the latter is the better. The reason
> is that .ini files are:
>
>    * Platform independant (can use the exact same routines on Unix)
>    * Easier to backup
>    * Easier to have more than one version of

So why are you even talking about the backend of storing program
configurations?  It would seem reasonable that you would want to define a
set of API's for storing program configuration.  This package would then
take advantage of the services offered (or not offered) by the operating
system.
This would allow for the compiler vendor to best determine how
configurations should be stored.  Sure, you might want to write an initial
package that provides the configuration services via .ini files for
usability test, but I would really like it if the configuration API is
customized to each system type.  This means that when you compile your
program for NT the program uses the registry and when you compile your
program for UNIX it uses configuration files.  This ways the end user
doesn't have to learn yet another configuration paradigm to reconfigure an
Ada program; they can use the operating system's paradigm.

-CRM

Re: A standard package for config files is needed

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ad0q6q$30r$1@nh.pace.co.uk>...
> Here's just a thought: The Grace components has the aim of creating a Map
> component. Assuming you can get serialization out of a Map component via
> 'Read, 'Write, 'Input & 'Output, it would be the natural data structure on
> which to build an INI file. If not Grace, perhaps some other package would

Doing that would not produce human-readable output (unless that human
is handy with "od" anyway :-) ). If having initialization files
human-readable and editable is a goal, then you would not want to use
stream attributes.

> Assuming we get a Grace component to do this, it might even make a nice
> extension to the Grace library - a descendent of Maps that handles
> initialization work?

Well...OpenToken was initially developed from a configuration file
reader. To my knowledge, that's still what it is most often used for.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[Ted Dennison]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnaf6onp.lpu.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Then there is the issue of the layout of the config file. Either one
> could do:
...

I think you need to get a bit more specific than you have here. The
reason is that a "configuration file reader" is, from the perspective
of the person who has to make the darned thing, nothing more than a
compiler (or at least a lexical analyzer). If you don't put strict
limits on the kind of configuration "languages" that will be
supported, you are going to need a general-purpose compiler
construction kit (like lex or OpenToken).

> I think this is a package that should be kept as simple as possible and
> easy to use and robust.

If simplicity is indeed that important of a goal, you *must* specify
the language.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[tmoran]

>The Java Property class is simple and easy to use! The Properties
>can be stored as an ASCI File, which is a  List of (Key,Value) pairs.
  In the Windows Registry case, the data is never accessed directly, so it
doesn't matter if it's ASCII or whatever.  If you are going to allow safe
concurrent access, the config file obviously can't be a simple ASCII file.
Instead there's a database manager frontend (nee regedit) to allow low
level mucking, and most changes are normally done via API calls under the
control of the relevant app itself.
Looking at Claw, I see, eg,
        -- Typical usage might be:
        --     Claw.Registry.Get(
        --           Root_Key   => Claw.Registry.HKEY_CURRENT_USER,
        --           Subkey     => "Software\MyCompany\ProgramName",
        --           Value_Name => "User_Nickname",
        --           Item       => Saved_String,
        --           Last       => Last);
and appropriate variations for stream io, record io (a la Sequential_IO),
etc.  Note also that Windows has the concept of branches of the
configuration tree for Users, Current_User, Local_Machine, Current_Config,
etc.  That's useful and should be considered for inclusion.

Re: A standard package for config files is needed

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ad0q6q$30r$1@nh.pace.co.uk>...
> narrowed down to the needs of an INI file. With a Map, you've got everything
> you need to store & query attribute/value pairs, eh? (Editing by hand might

If you were to use a Grace-style map, I think you'd have to view every
value as a string (most likely, an Ada.Strings.Unbounded_String). His
example showed numbers, which presumably folks would want to
manipulate as numbers, not strings. Then again, Ada's 'value makes it
pretty easy to do the transformation. However, the user would have to
handle any errors due to the value being the wrong type.

Its tough to tell from nothing more than an uncommented example, but
it looked like there was a wee bit more structure to it than just a
bunch of attribute/value pairs. If that's the case, Maps could
probably not be used, and a special structure might be required. It
would be nice to know how much structure there really should be, and
what it could be.

The way the NT registry works, Keys are stored in a hierarchy (think
of them as directories), and each one may have multiple "values". A
value has 3 attributes, its name, its *type*, and its actual value.
There are lots of different possible types, but in general they are
all a pain to deal with. :-)  Most folks just stick to the string or
string array types.

> Assuming we get a Grace component to do this, it might even make a nice
> extension to the Grace library - a descendent of Maps that handles

If we are talking of it as a standard Ada thing, then I agree.

Re: A standard package for config files is needed

[Ted Dennison]

volkert.barr@freenet.de (Volkert) wrote in message news:<39ee2480.0205282322.3bbd4673@posting.google.com>...
> The Ada Version should be a bit more powerfull. e.g store
> triples of (Scope,Key,Value), may be in be form you described
> above: Scope.Key=Value

In this scheme, do you think "scope"s should be flat (1 level only),
or should they be hierarchal (like Ada packages or the Microsoft
registry)?
 
-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[Simon Wright]

Darren New <dnew@san.rr.com> writes:

> I suspect he means to ask how the XML would look for the following
> .ini file:
> 
> name=Darren "The Dude" New
> relational=<=
> marriage=Wen's Husband
> this.city=San Diego
> 
> and so on.
> 
> There are advantages to using XML for this. Ease of hand-editting is
> not one of them.

Well, it's like the advantages of Ada; you stand at least some chance
of knowing that the data you put in matches what the program reading
it expects.

I would feel a lot more comfortable hand-editing an XML representation
than this sort of thing, one gets no idea what the range of input
might be.

Re: A standard package for config files is needed

[Simon Wright]

Preben Randhol <randhol+abuse@pvv.org> writes:

> Just to clarify, we are talking about config files not the file
> format of files stored by a program.

My current project has this problem (700 or so configurable variables
to be stored).

We are contemplating an API like

  function Value (Identified_By : String) return String;

and you get to use 'Value on the result (they are almost all numbers).

We think that Identified_By might take the form
"/box/component/subcomponent/item" which is pretty XPath-like.

How we store the data internally or on Flash is no one else's
business! We may well use XML, it's not that verbose. Perhaps not
appropriate for the config file for your toaster, though.

Re: A standard package for config files is needed

[Larry Kilgallen]

In article <3CF50B1A.3080503@mail.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Pascal Obry wrote:
>> I have one case were it does happen. I bought the Easy CD Creator 5.0 platinum
>> version. When installed on XP it has corrupted the Explorer icons. I had to
>> tweak the registry to get back icons for my removable drives... FUD certainly
>> not, but for sure it is quite rare.
> 
> This is clearly a case where the software is deliberately going
> out of its way to touch registry entries that don't belong to it.

I think the Registry approach encourages that sort of thing more
than separate configuration files do, since it makes it easier
for programmers to think they know how to do it correctly.

Re: A standard package for config files is needed

[Marin David Condic]

Well, my understanding of the original post was that it was a hypothetical
"Hey! Ada programs have to initialize themselves, so why don't we build
something to interpret initialization files or something similar to the
registry???" Not that it had to duplicate exactly what the registry does -
although there may be those who would want that.

So if you've got a general "Initialization" need - why could you not use
Maps? You look up something based on a key. The "something" could be a
string or it could be a record or whatever seemed to make sense for the
actual implementation. Decide what requirements need to be satisfied then
build the structure to suit that. If you want a tree-like structure, it
might be viewed as a Map of Maps. My idea was that if you had Maps
implemented, you could build a registry-like structure out of it as a basic
building block & end up with another useful component for Grace.

If we had a "Registry" (I use the term in the loose sense) package that was
built from Maps, it might make sense to build a "Registry Editing" package -
although this gets you into having to think about what sort of user
interface you want to support. It could suck it up and spit it out to a text
file, but I'm not sure I'd need that sort of behavior so long as my program
could set configuration information and then retrieve it next time it
started up. (Streams might be good enough for me.) I could see how others
would likely disagree, so I wouldn't consider it a hard requirement - but
then you get into arguing about what sort of format it should have. XML has
advantages in terms of it being able to get infinitely complex as needed,
but then you need a DOM as well as something to interpret it as a
"Registry".

Just a thought as to how to make Grace be more useful.....

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


"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205291059.737616ec@posting.google.com...
>
> If you were to use a Grace-style map, I think you'd have to view every
> value as a string (most likely, an Ada.Strings.Unbounded_String). His
> example showed numbers, which presumably folks would want to
> manipulate as numbers, not strings. Then again, Ada's 'value makes it
> pretty easy to do the transformation. However, the user would have to
> handle any errors due to the value being the wrong type.
>
> Its tough to tell from nothing more than an uncommented example, but
> it looked like there was a wee bit more structure to it than just a
> bunch of attribute/value pairs. If that's the case, Maps could
> probably not be used, and a special structure might be required. It
> would be nice to know how much structure there really should be, and
> what it could be.
>
> The way the NT registry works, Keys are stored in a hierarchy (think
> of them as directories), and each one may have multiple "values". A
> value has 3 attributes, its name, its *type*, and its actual value.
> There are lots of different possible types, but in general they are
> all a pain to deal with. :-)  Most folks just stick to the string or
> string array types.
>
> > Assuming we get a Grace component to do this, it might even make a nice
> > extension to the Grace library - a descendent of Maps that handles
>
> If we are talking of it as a standard Ada thing, then I agree.

Re: A standard package for config files is needed

[achrist]

Darren New wrote:
> 
> Preben Randhol wrote:
> > But we don't want to use any Windows API for reading .ini files.
> 
> Correct. My point is that since they're API compatible under Windows, one
> should strive to make them API compatible in the Ada implementation, where
> possible.
> 

If you are running under Windows and you don't want to use the Windows
API, you should not use *.ini file names.  Windows assumes that you
won't muck with ini files except through the Windows API's.  These 
should be off-limits to homegrown code going around the Windows APIs
just like the registry is,  because the Windows APIs link the two 
concepts in arbitrary ways.  Besides that, the suggestions that Ada 
could have something like java properties are pretty good.


Al

RE: The commercial world needs Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Darren New et al.

I have argued that Ada is a superb management tool. It motivates the
hackers to quit. Ada also selects for software engineers. Historically,
I have had trouble with Adaptec and its spin-off Roxio. 

Actually, it would be very difficult to separate the quality of a
language from the quality of the practitioners who select it. However,
the present sorry state of much of commercial software must be
correlated with its manufacturing techniques, which include the
programming language. Roxio's software does not seem to provide needed
exceptions, etc.
 
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Darren New
Sent: Wednesday, May 29, 2002 9:30 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: The commercial world needs Ada was RE: A standard package
for config files is needed

"Robert C. Leif" wrote:
> 1) it writes to my CDRW slightly
> faster than an XP does to a floppy disc and 2) control C does not work
> for copying a file, 3) if does not generate appropriate exceptions if
> your CDRW BIOS is not functioning correctly. An Ada program to manage
> writing to CDs should have the distinct commercial advantage of
working.

What makes you think any of these flaws are specifically caused by the
choice of language in which anything is programmed?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: The commercial world needs Ada was RE: A standard package for config files is needed

[Darren New]

Err, this has so many things wrong with it I'm not even going to begin to
try to say anything except "No."

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Volkert Barr]

tmoran@acm.org wrote:
> 
> >The Java Property class is simple and easy to use! The Properties
> >can be stored as an ASCI File, which is a  List of (Key,Value) pairs.
>   In the Windows Registry case, the data is never accessed directly, so it
> doesn't matter if it's ASCII or whatever.  If you are going to allow safe
> concurrent access, the config file obviously can't be a simple ASCII file.
> Instead there's a database manager frontend (nee regedit) to allow low
> level mucking, and most changes are normally done via API calls under the
> control of the relevant app itself.
> Looking at Claw, I see, eg,
>         -- Typical usage might be:
>         --     Claw.Registry.Get(
>         --           Root_Key   => Claw.Registry.HKEY_CURRENT_USER,
>         --           Subkey     => "Software\MyCompany\ProgramName",
>         --           Value_Name => "User_Nickname",
>         --           Item       => Saved_String,
>         --           Last       => Last);
> and appropriate variations for stream io, record io (a la Sequential_IO),
> etc.  Note also that Windows has the concept of branches of the
> configuration tree for Users, Current_User, Local_Machine, Current_Config,
> etc.  That's useful and should be considered for inclusion.

In my eyes, we would should seek for a simple useable solution first.

1) an application can handle (read/write) one or more config files!
2) a config file should store information in plain ASCII, so a 
   user can easily modify them by hand!
3) the config file should be simple organized:
   - All entries sould be of the form "scope.key := value"
   - Ada-like comment blocks
  
   (parsing this is very easy, so no other toolkits are needed)

If concurrent access is a need, we should take this
into account! But i did not see it! In later versions
more sophisticated features can be added, if we need 
them!

What about this location (Java-like API)

   Ada.Utilities;
   Ada.Utilities.Configuration
   Ada.Utilities. ...


Volkert

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - -
 Volkert Barr      Institut fuer Softwaretechnik und 
                             Theoretische Informatik
             Fachgruppe Softwaretechnik *  TU Berlin

 email: barr@cs.tu-berlin.de
 web: www.cs.tu-berlin.de/~barr
- - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: A standard package for config files is needed

[Volkert Barr]

Ted Dennison wrote:
> 
> volkert.barr@freenet.de (Volkert) wrote in message news:<39ee2480.0205282322.3bbd4673@posting.google.com>...
> > The Ada Version should be a bit more powerfull. e.g store
> > triples of (Scope,Key,Value), may be in be form you described
> > above: Scope.Key=Value
> 
> In this scheme, do you think "scope"s should be flat (1 level only),
> or should they be hierarchal (like Ada packages or the Microsoft
> registry)?

Flat should be ok, but why not an hierachical structure: ([Scope], Key,
Value)
As in Ada the level should be seperated by dots (.). 
This kind of structure is very easy to parse.

Volkert

Re: A standard package for config files is needed

[tmoran]

> 2) a config file should store information in plain ASCII, so a
>    user can easily modify them by hand!
> 3) the config file should be simple organized:
>    - All entries sould be of the form "scope.key := value"
>    - Ada-like comment blocks
  In a particular Windows program of mine the user can modify the color
settings (via the usual Windows color dialog), and the program will
save his preferences in the registry.  This is done with:

  type Shelf_Palettes is record ...
  procedure Stash_Palette is new Claw.Registry.Write(Shelf_Palettes);
  ...
  Stash_Palette(Claw.Registry.HKEY_CURRENT_USER,
                "Software\Decision Aids\Shelves",
                "Palette",
                Saved_Palette);

  That's pretty simple.  It appears to me you are suggesting that instead
I should write code to convert every element of Shelf_Palettes to a string
and write it out preceded with some suitable, human understandable,
"name=", and also write code to read such stuff back in, complete with
error handling when the user has botched up that text file.  That would be
a tremendous regression and I can't imagine anybody doing it.  Why should
the config file be an easily edited ASCII file?  Did everyone enjoy
editing .ini files in old Windows so much?  How often in current Windows
programs do users modify the config by doing things in the app (like the
color palette above), and how often do Windows users change a
configuration by using regedit?
  Considering how often real users should need to edit a config file
independently of the app or its Install program, I'm inclined to suggest
it would be easier to just read/write records in binary and tell the
user to use "debug" if he needs to modify them manually!
  There are also the questions of where the config file is stored, and
how multiple users of the same machine can have different configurations.
  The Windows registry certainly is an all too common failure point and as
a sort of parallel file system it's painful to backup/restore or uninstall
programs, but improvements in config files are not, I suggest, to be found
in better syntaxes for an ASCII text file.

Re: A standard package for config files is needed

[Volkert Barr]

tmoran@acm.org wrote:
> 
> > 2) a config file should store information in plain ASCII, so a
> >    user can easily modify them by hand!
> > 3) the config file should be simple organized:
> >    - All entries sould be of the form "scope.key := value"
> >    - Ada-like comment blocks
>   In a particular Windows program of mine the user can modify the color
> settings (via the usual Windows color dialog), and the program will
> save his preferences in the registry.  This is done with:
> 
>   type Shelf_Palettes is record ...
>   procedure Stash_Palette is new Claw.Registry.Write(Shelf_Palettes);
>   ...
>   Stash_Palette(Claw.Registry.HKEY_CURRENT_USER,
>                 "Software\Decision Aids\Shelves",
>                 "Palette",
>                 Saved_Palette);
> 
>   That's pretty simple.  It appears to me you are suggesting that instead
> I should write code to convert every element of Shelf_Palettes to a string
> and write it out preceded with some suitable, human understandable,
> "name=", and also write code to read such stuff back in, complete with
> error handling when the user has botched up that text file.  That would be
> a tremendous regression and I can't imagine anybody doing it.  Why should
> the config file be an easily edited ASCII file?  Did everyone enjoy
> editing .ini files in old Windows so much?  How often in current Windows
> programs do users modify the config by doing things in the app (like the
> color palette above), and how often do Windows users change a
> configuration by using regedit?
>   Considering how often real users should need to edit a config file
> independently of the app or its Install program, I'm inclined to suggest
> it would be easier to just read/write records in binary and tell the
> user to use "debug" if he needs to modify them manually!
>   There are also the questions of where the config file is stored, and
> how multiple users of the same machine can have different configurations.
>   The Windows registry certainly is an all too common failure point and as
> a sort of parallel file system it's painful to backup/restore or uninstall
> programs, but improvements in config files are not, I suggest, to be found
> in better syntaxes for an ASCII text file.

I have used this simple style in some projects to configure 
distributed systems. This works satisfactory good and the customer 
was easily able to set up (reconfigure) the whole system ... so what is 
wrong with simplicity!? 

Volkert
 
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - -
 Volkert Barr      Institut fuer Softwaretechnik und 
                             Theoretische Informatik
             Fachgruppe Softwaretechnik *  TU Berlin

 email: barr@cs.tu-berlin.de
 web: www.cs.tu-berlin.de/~barr
- - - - - - - - - - - - - - - - - - - - - - - - - - -
          * macrosolutions to megaproblems *

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - -
 Volkert Barr      Institut fuer Softwaretechnik und 
                             Theoretische Informatik
             Fachgruppe Softwaretechnik *  TU Berlin

 email: barr@cs.tu-berlin.de
 web: www.cs.tu-berlin.de/~barr
- - - - - - - - - - - - - - - - - - - - - - - - - - -
          * macrosolutions to megaproblems *

Re: A standard package for config files is needed

[Preben Randhol]

On Wed, 29 May 2002 14:42:40 -0700, achrist@easystreet.com wrote:
> 
> If you are running under Windows and you don't want to use the Windows
> API, you should not use *.ini file names.  Windows assumes that you
> won't muck with ini files except through the Windows API's.  These 
> should be off-limits to homegrown code going around the Windows APIs
> just like the registry is,  because the Windows APIs link the two 
> concepts in arbitrary ways.  Besides that, the suggestions that Ada 
> could have something like java properties are pretty good.

Noted. Thanks for the information.

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On 29 May 2002 20:24:44 +0100, Simon Wright wrote:
> Well, it's like the advantages of Ada; you stand at least some chance
> of knowing that the data you put in matches what the program reading
> it expects.

Absolutely not without a DTD.

> I would feel a lot more comfortable hand-editing an XML representation
> than this sort of thing, one gets no idea what the range of input
> might be.

? Please explain

Re: A standard package for config files is needed

[Marin David Condic]

I tend to agree that I don't see any big reason why a config file needs to
be in ASCII - so long as we're talking about an application preserving
various settings over its lifetime. (colors, fonts, user preferences of one
sort or another...) When you get to talking about things like "I need to
know what directory you installed XYZ in so I can find it and run..." then
you start seeing some need for ASCII - or at least some user-edit
capability.

Of course one could design apps to ask the user for this information on its
first execution or if it doesn't find what it wants & then store it from
there. It requires a little discipline in that case from the programming
side, but basically that means you don't have to store the data in any sort
of human readable format or worry about checking it for errors on input.
Building a data structure in memory and moving it in/out via Streams
provides an answer that is simple & portable to any platform. (You'd still
need to resolve how you would have different configurations for different
users, etc., but I could see that all as being resolved when designing the
"Ada Registry" package...)

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


<tmoran@acm.org> wrote in message
news:tulJ8.9347$7q5.169326745@newssvr14.news.prodigy.com...
>   The Windows registry certainly is an all too common failure point and as
> a sort of parallel file system it's painful to backup/restore or uninstall
> programs, but improvements in config files are not, I suggest, to be found
> in better syntaxes for an ASCII text file.

Re: A standard package for config files is needed

[Gautier]

Al:

> If you are running under Windows and you don't want to use the Windows
> API, you should not use *.ini file names.  Windows assumes that you
> won't muck with ini files except through the Windows API's.

Are you sure of it ? My impression is that Windows lets the .ini files
in peace, unless the program using the .ini uses the Windows API for I/O
- like any other text file!
If you search for "*.ini" files on your PC, the concerned files often
don't have the "Windows" format. Many of them are Free Software developped
on other systems or before Windows supremacy: (La)TeX, for example.
A nearer counter-example: AdaGIDE. It reads & writes its .ini bravely
with Ada.Text_IO.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, address on the Web site!

Re: A standard package for config files is needed

[Stephen Leake]

tmoran@acm.org writes:

> It appears to me you are suggesting that instead
> I should write code to convert every element of Shelf_Palettes to a string
> and write it out preceded with some suitable, human understandable,
> "name=", and also write code to read such stuff back in, complete with
> error handling when the user has botched up that text file.  That would be
> a tremendous regression and I can't imagine anybody doing it.  

For this application, the registry (or at least some sort of binary
storage) is clearly better.

> Why should the config file be an easily edited ASCII file? 

There are times when either a human or a config script needs to edit a
configuration setting. For example, the absolute path to the bin
directory, or the lib directory, or the pdf directory. There were many
times in Windows apps when I wish I could have changed D:\ to E:\ in
the apps config, because I installed a new zip drive and everything
moved! 

> Did everyone enjoy editing .ini files in old Windows so much? 

Not "enjoy" so much as "needed to".

I suppose the RegEdit tool satisfies this need on Windows. If we can
guarrantee the existence of a similar tool on all other systems, the
requirement for human editable goes away. I _know_ I will have an
ASCII text editor on any system I will use; I don't know I will have a
"registry editor".

> How often in current Windows programs do users modify the config by
> doing things in the app (like the color palette above), and how
> often do Windows users change a configuration by using regedit?

Perhaps not "very often", but "often enough" that it is a perceived
need.

I believe we need both the "registry style" and the "ini file style"
of config settings. Part of this discussion is to figure out where to
draw the line between them.

The registry supports simultaneous access by multiple processes; that
can be very useful. ini files don't; that can also be useful. So that
is one clear line between them.

One thing I'm looking for in "config files" is to be able to specify
the file name on the command line of the app (or in a user dialog, or
some such). This allows customizing specific instances of an app.

> The Windows registry certainly is an all too common failure point
> and as a sort of parallel file system it's painful to backup/restore
> or uninstall programs, but improvements in config files are not, I
> suggest, to be found in better syntaxes for an ASCII text file.

Well, ok. Where are improvements to be found?

-- 
-- Stephe

Re: A standard package for config files is needed

[Preben Randhol]

On 30 May 2002 11:08:45 -0400, Stephen Leake wrote:
> 
> I believe we need both the "registry style" and the "ini file style"
> of config settings. Part of this discussion is to figure out where to
> draw the line between them.
> 
> The registry supports simultaneous access by multiple processes; that
> can be very useful. ini files don't; that can also be useful. So that
> is one clear line between them.
> 
> One thing I'm looking for in "config files" is to be able to specify
> the file name on the command line of the app (or in a user dialog, or
> some such). This allows customizing specific instances of an app.

Another point is that .ini files are platform independant (can be copied
from windows to Linux and visa versa) while registries are not. We would
probably need both, but I think that starting with .ini is best. I guess
there are some API for the Windows registry we can use and same for
gconf for Gnome.

Preben

Re: A standard package for config files is needed

[achrist]

Gautier wrote:
> 
> Are you sure of it ? My impression is that Windows lets the .ini files
> in peace, unless the program using the .ini uses the Windows API for 
>  I/O - like any other text file!

Sure.  If you never use the ini file API for ini files, it
will leave it right there AFAIK.  If you know that no other application 
will ever try to access your app's ini file and you make sure that
only one copy of your app is running at once,  you don't have to 
worry about simultaneous accesses and updates. If everyone always
does everything your way, it will work just fine.

However, there are something like a dozen functions in the Windows
API for accessing and updating ini file data.  Depending on what version
of Windows, these functions may cache data, may share data if accesses
to the same data come from multiple processes, and MS more or less
reserved the right to move the ini file right into the registry without
any further ado, if and when they wanted to.  IOW, the OS vendor wants
you to use their 12+ functions to access this data.  If everyone always
does everything the MS way, it will work just fine.  

Al

Re: A standard package for config files is needed

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ad3bbh$p54$1@nh.pace.co.uk>...
> Well, my understanding of the original post was that it was a hypothetical
...
> registry???" Not that it had to duplicate exactly what the registry does -
> although there may be those who would want that.

What I'm trying to get a gauge for is if it is possible to get any
kind of agreement on what format or language to use.

> build the structure to suit that. If you want a tree-like structure, it
> might be viewed as a Map of Maps. My idea was that if you had Maps

Hmmmm. I suppose it could at that.


> If we had a "Registry" (I use the term in the loose sense) package that was
> built from Maps, it might make sense to build a "Registry Editing" package -

I'd think you want the ability to load mappings from a file
(obviously), save mappings out to a file, and edit it with a simple
text editor.

The file format for something like this has to be flat text for a
number of reasons, not limited to:

   o Useability - On many systems the whole point of a configuration
file is that it can be edited off-line without using any special tools
or programs.
   o Portability - Use of this package should not, in and of itself,
render a system non-portable. It would be almost impossible to come up
with a binary format that is portable. It can be done, but using text
as the format is probably the easiest way.


You are absolutely right that this opens a big can of worms as to what
the proper format should be. That's why I'm most interested in if its
possible to reach some kind of consensus on what the format should be.

Just to lift another rock; I've seen programs that use CSV for
configuration files. This allows the files to be easily manipluated
with common database or spreadsheet tools. It also allows for easy
addition of all sorts of attributes.

Re: A standard package for config files is needed

[Preben Randhol]

On 30 May 2002 10:52:28 -0700, Ted Dennison wrote:
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ad3bbh$p54$1@nh.pace.co.uk>...
>> Well, my understanding of the original post was that it was a hypothetical
> ...
>> registry???" Not that it had to duplicate exactly what the registry does -

No.

> The file format for something like this has to be flat text for a
> number of reasons, not limited to:
> 
>    o Useability - On many systems the whole point of a configuration
> file is that it can be edited off-line without using any special tools
> or programs.
>    o Portability - Use of this package should not, in and of itself,
> render a system non-portable. It would be almost impossible to come up
> with a binary format that is portable. It can be done, but using text
> as the format is probably the easiest way.

Good.

> You are absolutely right that this opens a big can of worms as to what
> the proper format should be. That's why I'm most interested in if its
> possible to reach some kind of consensus on what the format should be.

Yes

> Just to lift another rock; I've seen programs that use CSV for
> configuration files. This allows the files to be easily manipluated
> with common database or spreadsheet tools. It also allows for easy
> addition of all sorts of attributes.

Lets keep it simple. I don't know what CSV is, but if somebody has to
install a database to use my small program then I think they would look
elsewhere. Me too for that matter :-)

Although tangent-surfing can be fun exercise for the mind, let's try not
to do it. I would like a package that can be used on any platform without
problems. If I am to run an application on both windows and linux (as
Ada gives me this possibility) I am not interested in configuring the
program twice. I want to do it on one of the platforms and then simply
copy the configuration file to the other. The only exception is of
course when directory paths are in the configuration file, but this is
of no concern to the package in question.

If people want to use the Window register and make a Windows only
application, it is fine by me, but at least this should be put in a
separate package.

Preben

Re: A standard package for config files is needed

[Jacob Sparre Andersen]

Preben Randhol wrote:

> On the GtkAda list there has been some discussion on making a standard
> package for reading/writing configuration files. As most programs need
> this it would be very nice with a small, platform independant, robust
> but easy to use package.

Yes.

If we take a look at the specification (API) side of things
first, then I think such a package would need:

 + (generic?) routines to read and write primitive Ada types
   from/to the configuration data.

 + The data should be stored as key-value pairs, possibly
   embedded in in a hierarchical system of sections.

 + A routine for syncronising the configuration data with
   the external storage in case that is relevant.

 + An option to select another source/target than the
   default storage of the configuration data.

Are there more things we should keep in mind, when
discussing the specification for a simple configuration
management package?

If we take a look at the implementation (file format) side
of things, there are a few things worth noting:

 + Using the same file format on all systems makes it
   slightly easier to write documentation for programs using
   the package (unless the package includes a function
   returning the file format documentation).

 + Using a text based file format makes it easier to copy
   configuration files between different platforms.

 + Using a text based file format allows users to use
   independent tools (for example text editors) to modify
   the configuration.

 + Using a platform specific binary format may make access
   to the configuration data faster.

 + Using typical (or standard) configuration management for
   the individual platforms, will allow users to configure
   programs in a way they are familiar with.

And since the specification and implementation sides of
things can be relatively independent of each other, nothing
prevents us from writing more than one implementation, so
everybody can get to use their choice of configuration files
(also for programs written by other Ada programmers ;-).

Jacob
-- 
"Those who profess to favor freedom and yet depreciate
 agitation, are people who want crops without ploughing the
 ground; they want rain without thunder and lightning; they
 want the ocean without the roar of its waters."
                                        -- Frederick Douglas

Re: A standard package for config files is needed

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0205300952.192e8274@posting.google.com...
>
>    o Useability - On many systems the whole point of a configuration
> file is that it can be edited off-line without using any special tools
> or programs.

I think that depends on what sort of usage model one puts forth for it. If
the model is to have the program check its registry and update anything
(based on user interaction or other means) that it must have in order to
run, then it doesn't have to come from a text file. This has the advantage
that it doesn't need to do any error checking, parsing, etc. You just read
it and write it as a stream.

I see the point of going to ASCII. But then its got to do a lot more work &
I'm not sure there's enough value to outweigh the negatives. If its got to
be in ASCII, I'd like to see it in an XML format - so we'd have an excuse to
need an XML parser & DOM as part of Grace. :-) Including that would add a
lot more value.

>    o Portability - Use of this package should not, in and of itself,
> render a system non-portable. It would be almost impossible to come up
> with a binary format that is portable. It can be done, but using text
> as the format is probably the easiest way.
>
You mean "Portability" in the sense of writing the INI/Registry on one
system and moving the file to another system? Depending on how its used, I
don't think it would need to do that very much. If its saving installation
information and locations of various important files/directories, that is
going to be system dependent anyway. If its remembering a user's
preferences, installing somewhere else probably is for a different user
and/or isn't going to be that big a deal for a user to reconfigure anyway. I
can't think of any circumstances where I'd want to lift the Registry from
Windows and move it to a Unix system. Why would I care that I can't do this
with the AdaINIRegistry?


>
> You are absolutely right that this opens a big can of worms as to what
> the proper format should be. That's why I'm most interested in if its
> possible to reach some kind of consensus on what the format should be.
>
XML - maybe its overkill, but it means developing other things that can be
used in other places. We create more leverage.


> Just to lift another rock; I've seen programs that use CSV for
> configuration files. This allows the files to be easily manipluated
> with common database or spreadsheet tools. It also allows for easy
> addition of all sorts of attributes.

Never seen that and wouldn't know how to comment on it. No reason why a
self-contained Ada package for Ada programming purposes would need to do
anything other than whatever we want it to do, so I doubt it would have to
utilize CSV or anything else. It doesn't have to be backwards-compatible. It
has to satisfy the needs of some large body of Ada programmers & that's
about it.

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

Re: A standard package for config files is needed

[Marin David Condic]

O.K. What's wrong with this idea? The package stores/retrieves its data as
some binary format, but the package has operations to import and export the
data as some kind of ASCII format. Hence, you'd be able to operate
day-to-day in binary format but if someone needed to use ASCII for some
occasional hand-updating or porting, that capacity could be readily built.
It would possibly avoid any need to do heavy error-checking on the ASCII
file - just reject anything that is unrecognizable & force the user to get
it right.

Seems like that would be a compromise that might make everyone happy?

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


"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:3CF6846C.3544EB21@nbi.dk...
>
>  + Using a text based file format allows users to use
>    independent tools (for example text editors) to modify
>    the configuration.
>
>  + Using a platform specific binary format may make access
>    to the configuration data faster.
>

Re: A standard package for config files is needed

[Darren New]

Preben Randhol wrote:
> Lets keep it simple. I don't know what CSV is, but if somebody has to
> install a database to use my small program then I think they would look
> elsewhere. Me too for that matter :-)

CSV is Comma-Separated-Values. A spreadsheet would look something like

"r1c1", "r1c2", "r1c3"
"r2c1", "r2c2", "r2c3"

Works well when your configuration is a table rather than a bunch of
individual thingies.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Darren New]

Jacob Sparre Andersen wrote:
> And since the specification and implementation sides of
> things can be relatively independent of each other, nothing
> prevents us from writing more than one implementation, so
> everybody can get to use their choice of configuration files
> (also for programs written by other Ada programmers ;-).

This is one of the things I (and others, of course) was originally
commenting would be good. Indeed, why not make the text-file format the same
as that output by Microsoft's regedit program when you export a portion of
the registry? Then you could have seemless interoperation between packages
that use MS's registry, UNIX-based files, and flat files under MS windows.
You could export your configuration back and forth while still making it
compatible with platform-specific registry operations.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Mats Karlssohn]

Ted Dennison wrote:
> 
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ad3bbh$p54$1@nh.pace.co.uk>...
%<
> > build the structure to suit that. If you want a tree-like structure, it
> > might be viewed as a Map of Maps. My idea was that if you had Maps
> 
> Hmmmm. I suppose it could at that.

yes, I think that a config file maps nicely onto a map of maps...

Sorry, I couldn't resist the [pf]un :-)

%<
> You are absolutely right that this opens a big can of worms as to what
> the proper format should be. That's why I'm most interested in if its
> possible to reach some kind of consensus on what the format should be.

Do we really need consensus regarding the storage format ?

I'm thinking on the lines of a nice abstract interface with multiple
possible implementations where the user may pick the one that fits
best with his/her current requirements. And yes, I realize that this
will probably mean some more generic instasiation (spl ?) that may
seem silly for novice users, however that may be owercome by providing
preinstansiated packages for the common case.

On windows there should be an implementation that maps to the
registry API. On all systems plain text files should be possibly,
probably in different flavours: windows .ini file, maybe the format
windows regedit imports/exports, XML in some form(s ?).
Other more esoteric implementations could use a database, the
Application Configuration Access Protocol (RFC 2244), LDAP and so on.

I think what we need is consensus on a general abstract interface for
configuration data access, that can have multiple different
implementations (possibly in the same program, think of a
"configuration file converter).

Marin's suggestion of accessing the configuration data as a map of
maps is IMHO quite nice.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: A standard package for config files is needed

[Preben Randhol]

On Thu, 30 May 2002 16:12:52 -0400, Marin David Condic wrote:
> O.K. What's wrong with this idea? The package stores/retrieves its data as
> some binary format, but the package has operations to import and export the
> data as some kind of ASCII format. Hence, you'd be able to operate
> day-to-day in binary format but if someone needed to use ASCII for some
> occasional hand-updating or porting, that capacity could be readily built.
> It would possibly avoid any need to do heavy error-checking on the ASCII
> file - just reject anything that is unrecognizable & force the user to get
> it right.

Why why why do we need binary format? We are talking about configuration
files not data files. When was the time to load a configuration file in
any way a time-hog?

Preben

Re: A standard package for config files is needed

[Georg Bauhaus]

tmoran@acm.org wrote:
:   so it
: doesn't matter if it's ASCII or whatever.  If you are going to allow safe
: concurrent access, the config file obviously can't be a simple ASCII file.

Not only that. It seems quite plausible, with Ada being capable of
handling a substantial subset of Unicode, and for more than one
other reason, to store something more than
(US) American Standard Code for Information Interchange
wich isn't even enough for directly storing all US american words,
let alone anything that might be needed in Canada, Brazil,
Russia, France, Korea, Egypt, Japan, ...
(E.g. error messages.)

If your editors aren't capable of handling anything but 7bit
or latin1 or some such, and you use that as an argument to
_always_ stay with ASCII, then the ASCII anachronism is likely to last.
I wouldn't like to edit Strings like "r[00F4]le" with a lookup-table
open in another window (or a print of such a table on my desk)
essentially for eye-movement trainging.  For compatibility,  like with
6 bit computers, where "ASCII-Editors" vi or notepad or whatever won't help,
there is still enough power in Ada to build a suitable abstraction,
so you could write a program for config file inspection for any
mechanism, including a 6 bit characters text file.

Re: A standard package for config files is needed

[Florian Weimer]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Not only that. It seems quite plausible, with Ada being capable of
> handling a substantial subset of Unicode,

I wouldn't bet on this.  At least one implementor views Wide_Character
as a data type which scan 2**16 code positions for characters, and not
tied strictly to Unicode. :-(

Re: A standard package for config files is needed

[Marin David Condic]

You'll have to forgive us old timers. When we say "ASCII" what we mean is
"Text". So Unicode in some manner would be (at least in my mind)
fundamentally the same thing.

Not that I am more in favor of it if the format is Unicode instead of
ASCII - I still think it ought to be just a Stream file of a data structure
held in memory. But if the consensus is to put it in some text format, you
can go ahead and make it 32-bit Unicode so you can support hieroglyphics and
ancient sandscrit and I'll still be calling it ASCII :-)

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


"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:ad7edf$phc$1@a1-hrz.uni-duisburg.de...
>
> Not only that. It seems quite plausible, with Ada being capable of
> handling a substantial subset of Unicode, and for more than one
> other reason, to store something more than
> (US) American Standard Code for Information Interchange
> wich isn't even enough for directly storing all US american words,
> let alone anything that might be needed in Canada, Brazil,
> Russia, France, Korea, Egypt, Japan, ...
> (E.g. error messages.)
>

Re: A standard package for config files is needed

[Marin David Condic]

The reason is not for efficiency. The reason is that if the file is created
under program control and is not editable by other means, then you can't
fill it with corrupt data. Hence you don't have to check it on the way in to
be sure some bonehead didn't screw up the syntax. It also makes the
implementation a much simpler thing because there doesn't need to be a
parser. IOW, it keeps it down to the level of something that is likely to
get implemented and actually work rather than something that will get
discussed to death and have everyone waiting around for someone else to
write a billion lines of code to correctly handle every conceivable text
file format, syntax, internal representation, etc.

Keep it simple and get the job done & maybe we'll have something actual and
useful rather than abstract and theoretical. :-)

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


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnafea2h.5hu.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> Why why why do we need binary format? We are talking about configuration
> files not data files. When was the time to load a configuration file in
> any way a time-hog?
>
> Preben

Re: A standard package for config files is needed

[Stephen Leake]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> And since the specification and implementation sides of
> things can be relatively independent of each other, nothing
> prevents us from writing more than one implementation, so
> everybody can get to use their choice of configuration files
> (also for programs written by other Ada programmers ;-).

The nice thing about standards is there are so many to choose from :).

I like all your other points. I'll be posting a summary of this
discussion on my web site soon (since I'm the one that started it on
GtkAda). 

-- 
-- Stephe

Re: A standard package for config files is needed

[Stephen Leake]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> tmoran@acm.org wrote:
> :   so it
> : doesn't matter if it's ASCII or whatever.  If you are going to allow safe
> : concurrent access, the config file obviously can't be a simple ASCII file.
> 
> Not only that. It seems quite plausible, with Ada being capable of
> handling a substantial subset of Unicode, and for more than one
> other reason, to store something more than
> (US) American Standard Code for Information Interchange
> wich isn't even enough for directly storing all US american words,
> let alone anything that might be needed in Canada, Brazil,
> Russia, France, Korea, Egypt, Japan, ...
> (E.g. error messages.)

Excellent point. Let's at least consider using Wide_String. We'll have
to convert to String to use 'Value, but that's not a big deal.

-- 
-- Stephe

Re: A standard package for config files is needed

[Marin David Condic]

Just to add some useful meat to my own little rant... :-)

Suppose that we were to get a good spec written for Grace.Maps & have that
up and working. Suppose that we built on top of this some version of
"Grace.AdaINIRegistryWhozits" that implemented some version of a tree-ish,
registry-ish, thingamabob that is built out of Grace.Maps. Provided you've
got your 'Input and 'Output and make a Load and Store operation for the data
structure, you *instantly* have a usable registry/initialization thing.
Programs can use it to set up and retrieve all of their configuration
information and we're off to the races.

From there, you can start adding child packages:

"Grace.AdaINIRegistryWhozits.Import_Export_CSV_Files"
"Grace.AdaINIRegistryWhozits.Import_Export_Windows_Registry"
"Grace.AdaINIRegistryWhozits.Import_Export_Flat_ASCII_Files"
"Grace.AdaINIRegistryWhozits.Import_Export_XML_Files"

or just about any other bizarre thing you can dream up. If the market seems
to like to use it to connect up to some sort of XML file, then this becomes
the dominant mechanism and you don't need to load and store the binary
format at all.

But the *real* advantage to this strategy is that you get a usable, real,
component quickly and if you want to provide other capabilities at a later
point, this isn't a problem. Connecting to specific OS capabilities ("The
Registry") could be hidden beneath some additional package. Providing some
sort of mutex capabilities via a database or something could be added on.
Whatever the needs are, you get there eventually.

But why agonize over all these details now? We can burn those bridges when
we get to them. :-) Opt for something simple & realizable within our
lifetimes & maybe it will get done. Isn't that keeping within the whole
spirit of "Open Source" and "Bizarre Development" :-)

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


"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:ad7tcf$sto$1@nh.pace.co.uk...
>
> Keep it simple and get the job done & maybe we'll have something actual
and
> useful rather than abstract and theoretical. :-)
>

Re: A standard package for config files is needed

[Ted Dennison]

Darren New <dnew@san.rr.com> wrote in message news:<3CF6AE0E.3847AA4F@san.rr.com>...
> Preben Randhol wrote:
> > Lets keep it simple. I don't know what CSV is, but if somebody has to
> > install a database to use my small program then I think they would look
> > elsewhere. Me too for that matter :-)
> 
> CSV is Comma-Separated-Values. A spreadsheet would look something like
> 
> "r1c1", "r1c2", "r1c3"
> "r2c1", "r2c2", "r2c3"
> 
> Works well when your configuration is a table rather than a bunch of
> individual thingies.

Right. Just to make things perfectly clear, its a *text* format, with
some structure to it. The number 32 in a field would show up as 32,
not a.

On the project I worked on that used them, I usually used Emacs to
edit the files, rather than bother with a spreadsheet or DB program.
But some people did prefer the database program, and having in that
format allows people to do DB queries on the file (quite useful if it
gets large).

Not that this is the option I'm pushing. Its just *an* option.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[Ted Dennison]

"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1022683322.20042.comp.lang.ada@ada.eu.org>...
> XML has two advantages over Ada. 1) More users and 2) eventually more
> tools. It has the disadvantage, that except for XSL Fo, XML lacks

Those are both just theory. I'd like to see numbers on 1, and 2 is a
prediction, which could be no better than my World Cup predictions.
:-)

What we *do* know is right now. Right now, anyone who is going to use
this is going to already be using Ada, and there are *far* less tools
for dealing with XML files than there are for dealing with CSV files.

(Can you tell I'm not an XML convert? :-) )

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[Ted Dennison]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<ad5a2j$5jj$1@nh.pace.co.uk>...
> Building a data structure in memory and moving it in/out via Streams
> provides an answer that is simple & portable to any platform. (You'd still

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).

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.

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).

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[Preben Randhol]

On 29 May 2002 20:29:38 +0100, Simon Wright wrote:
> Preben Randhol <randhol+abuse@pvv.org> writes:
> 
>> Just to clarify, we are talking about config files not the file
>> format of files stored by a program.
> 
> My current project has this problem (700 or so configurable variables
> to be stored).

> 
> We are contemplating an API like
> 
>   function Value (Identified_By : String) return String;
> 
> and you get to use 'Value on the result (they are almost all numbers).

:-)

> We think that Identified_By might take the form
> "/box/component/subcomponent/item" which is pretty XPath-like.

Sounds ok

> How we store the data internally or on Flash is no one else's
> business! We may well use XML, it's not that verbose. Perhaps not
> appropriate for the config file for your toaster, though.

Of course.

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Thu, 30 May 2002 08:34:33 GMT, tmoran@acm.org wrote:
>   In a particular Windows program of mine the user can modify the color
> settings (via the usual Windows color dialog), and the program will
> save his preferences in the registry.  This is done with:

Can I get a Linux version of this program?


>   type Shelf_Palettes is record ...
>   procedure Stash_Palette is new Claw.Registry.Write(Shelf_Palettes);
>   ...
>   Stash_Palette(Claw.Registry.HKEY_CURRENT_USER,
>                 "Software\Decision Aids\Shelves",
>                 "Palette",
>                 Saved_Palette);
> 
>   That's pretty simple.  It appears to me you are suggesting that instead
> I should write code to convert every element of Shelf_Palettes to a string
> and write it out preceded with some suitable, human understandable,
> "name=", and also write code to read such stuff back in, complete with
> error handling when the user has botched up that text file. 

No. The name would of course be Palette like you use for the registry.
But I encourage you to use the Windows registry as long as you only care
about windows users. Just don't claim that your code is portable because
you use Ada.

> a tremendous regression and I can't imagine anybody doing it.  Why should
> the config file be an easily edited ASCII file?  Did everyone enjoy
> editing .ini files in old Windows so much?  How often in current Windows
> programs do users modify the config by doing things in the app (like the
> color palette above), and how often do Windows users change a
> configuration by using regedit?

Sorry but I simply don't care for Windows only solutions.

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Thu, 30 May 2002 09:49:58 +0200, Volkert Barr wrote:
> 
> Flat should be ok, but why not an hierachical structure: ([Scope], Key,
> Value)
> As in Ada the level should be seperated by dots (.). 
> This kind of structure is very easy to parse.

Yes, I agree.

Re: A standard package for config files is needed

[Preben Randhol]

On 31 May 2002 09:25:18 -0700, Ted Dennison wrote:
> 
> 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.

Exactly. Besides even if you make a GUI application you may need to
release it before you have had time to make GUI interface to *all* the
possible settings. Many of the settings may only be for powerusers so
they may as well edit the config file directly. I think earlier versions of GVD
worked like this although I'm not 100% sure.

> 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).

Yes :-)

One thing I'm sitting and thinking about now is if it is possible to
make a procedure for storing a record or array and reading this back. I
mean a generic procedure.

Preben

Re: A standard package for config files is needed

[Marin David Condic]

"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

Re: A standard package for config files is needed

[tmoran]

> Can I get a Linux version of this program?
  No, nor Macintosh nor Palm nor OS360.  There is a 16 bit DOS version,
but that uses "hires" 640x480 graphics and thus doesn't need a color
palette.
> >   type Shelf_Palettes is record ...
> >   procedure Stash_Palette is new Claw.Registry.Write(Shelf_Palettes);
  Or are you implying that Linux programs don't need any structured data,
ie records, in their configuration files?

> Just don't claim that your code is portable because you use Ada.
  Who is dumb or dishonest enough to claim the use of Ada automatically
makes something machine or OS independent?

> Sorry but I simply don't care for Windows only solutions.
  Nor do I.  I'd much rather be able to port to such popular systems
as the Macintosh or the Palm OS, but that appears to be less than
straightforward.  Perhaps in the future there will be just one
OS and machine architecture that replaces Wintel, runs on everthing
from toasters to supercomputer clusters, and an Ada compiler
for it.  MS Windows, including CE, doesn't seem to have quite
made it that far.  I look forward to seeing the above program, which
displays disk usage on a hi-res color display, run on a toaster.

Re: A standard package for config files is needed

[tmoran]

> ...  I usually used Emacs to edit the files, rather than bother with
> a spreadsheet or DB program.  But some people did prefer the database
> program, and having in that format allows people to do DB queries on

  I'm starting to wonder if everyone is thinking of the same thing when
they use the term "configuration data".  Or are we all on different
wavelengths here.  I myself am thinking of persistent information that
is specific to a particular user and installation, but not a particular
execution (eg, not an individual document in the case of a word
processing program).  I also include information that is needed for
installation and un-installation on a machine, independent of the
particular user.  That's a pretty broad definition, including file
lists and file paths and such text as, for instance, standard
signatures.  My definition also includes settings of flags and
semi-constants, including structured constants like color palettes or
fonts.  Those are typically not textual and understanding them requires
at least some understanding of the inner workings of the program.  Does
that jibe with what the term is meaning to other folks?

RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Mats Karlssohn et al.
If the application involves files or similar objects, it should be a
database. A POSIX file system based on an XML database might be a good
product. One could then interface (layer) the same file system to the
Windows file system. I believe that one of the original Ada
specifications mentioned an operating system that included a database.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Mats Karlssohn
Sent: Thursday, May 30, 2002 11:44 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed

Ted Dennison wrote:
> 
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote
in message news:<ad3bbh$p54$1@nh.pace.co.uk>...
%<
> > build the structure to suit that. If you want a tree-like structure,
it
> > might be viewed as a Map of Maps. My idea was that if you had Maps
> 
> Hmmmm. I suppose it could at that.

yes, I think that a config file maps nicely onto a map of maps...

Sorry, I couldn't resist the [pf]un :-)

%<
> You are absolutely right that this opens a big can of worms as to what
> the proper format should be. That's why I'm most interested in if its
> possible to reach some kind of consensus on what the format should be.

Do we really need consensus regarding the storage format ?

I'm thinking on the lines of a nice abstract interface with multiple
possible implementations where the user may pick the one that fits
best with his/her current requirements. And yes, I realize that this
will probably mean some more generic instasiation (spl ?) that may
seem silly for novice users, however that may be owercome by providing
preinstansiated packages for the common case.

On windows there should be an implementation that maps to the
registry API. On all systems plain text files should be possibly,
probably in different flavours: windows .ini file, maybe the format
windows regedit imports/exports, XML in some form(s ?).
Other more esoteric implementations could use a database, the
Application Configuration Access Protocol (RFC 2244), LDAP and so on.

I think what we need is consensus on a general abstract interface for
configuration data access, that can have multiple different
implementations (possibly in the same program, think of a
"configuration file converter).

Marin's suggestion of accessing the configuration data as a map of
maps is IMHO quite nice.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: A standard package for config files is needed

[Ted Dennison]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnaffafb.27t.randhol+abuse@kiuk0156.chembio.ntnu.no>...
> One thing I'm sitting and thinking about now is if it is possible to
> make a procedure for storing a record or array and reading this back. I
> mean a generic procedure.

It'd be pretty easy, as long as the generic can own the array type.


Hmmm. One thing I'm thinking is that this task might be a bit easier
if the new version of Ada had the following:

  o  The ability to specify the 'Image routine for user-defined types.
  o  'Image being defined by default to perform a 'Image on each
component of a composite type (in order).

Not being a compiler writer, I have no idea what kinds of cans of
worms this would open for them though.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Ted Dennison et al.
Microsoft, SUN, and IBM are converts. For instance, one can import an
XML file into Excel. 

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Ted Dennison
Sent: Friday, May 31, 2002 9:02 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed

"Robert C. Leif" <rleif@rleif.com> wrote in message
news:<mailman.1022683322.20042.comp.lang.ada@ada.eu.org>...
> XML has two advantages over Ada. 1) More users and 2) eventually more
> tools. It has the disadvantage, that except for XSL Fo, XML lacks

Those are both just theory. I'd like to see numbers on 1, and 2 is a
prediction, which could be no better than my World Cup predictions.
:-)

What we *do* know is right now. Right now, anyone who is going to use
this is going to already be using Ada, and there are *far* less tools
for dealing with XML files than there are for dealing with CSV files.

(Can you tell I'm not an XML convert? :-) )

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: A standard package for config files is needed

[Preben Randhol]

On Fri, 31 May 2002 09:21:18 -0400, Marin David Condic wrote:
> The reason is not for efficiency. The reason is that if the file is created
> under program control and is not editable by other means, then you can't
> fill it with corrupt data. Hence you don't have to check it on the way in to
> be sure some bonehead didn't screw up the syntax. It also makes the
> implementation a much simpler thing because there doesn't need to be a
> parser. 

Yes this is a nice feature and is of course very usable especially for
storing a lot of variables. I think Matlab does something like this (I
haven't seen the code of course, but I remember one could dump all
variables to a binary file that Matlab could read later)? 

However I still would also like to see a human editable text file that
one could *choose* to use the application one use.

> IOW, it keeps it down to the level of something that is likely to
> get implemented and actually work rather than something that will get
> discussed to death and have everyone waiting around for someone else to
> write a billion lines of code to correctly handle every conceivable text
> file format, syntax, internal representation, etc.

I agree with you, and that is why I would like to have *one* text
format which is simple to parse and gives a small package.

We should probably do all the below:

      1) Make a parser for reading/writing human editable text files
      2) Use XML
      3) Make a AdaRegistry
      4) Make interface to Window Registry and gconf (GNOME)
      5) Use streams
      6) Grace.Maps ?

But I really think that they should be split up in 6 parts so that one
can choose which package one wants to use. The other point is that we
don't know if there is a need for all these different packages at the
moment. So personally I would like to see 1) happening as a seperate
project :-)

> Keep it simple and get the job done & maybe we'll have something actual and
> useful rather than abstract and theoretical. :-)

Yes :-) This is what I'm trying to get at too.

Re: A standard package for config files is needed

[Preben Randhol]

On Fri, 31 May 2002 09:46:14 -0400, Marin David Condic wrote:
> Just to add some useful meat to my own little rant... :-)
> 
> Suppose that we were to get a good spec written for Grace.Maps & have that
> up and working. Suppose that we built on top of this some version of

Yes, but getting a good spec is far from having a working version :-) Somebody
once said: "Development is 25% planning, 75% work (as in implementing++).
More planning will lead to that nothing gets done as more and more
special cases are found." Of course where the percentage line goes is
not important, but there is something like planning yourself to death.
We have an expression (there is probably an English equivalent) "One
feather became ten hens" :-)

> "Grace.AdaINIRegistryWhozits" that implemented some version of a tree-ish,
> registry-ish, thingamabob that is built out of Grace.Maps. Provided you've
> got your 'Input and 'Output and make a Load and Store operation for the data
> structure, you *instantly* have a usable registry/initialization thing.
> Programs can use it to set up and retrieve all of their configuration
> information and we're off to the races.
>

> From there, you can start adding child packages:

Yes, but if we make the Import_Export_Flat_ASCII_Files parser now we
just have to put this as a child package if/when an AdaINIRegistry
emerges :-)

> But the *real* advantage to this strategy is that you get a usable, real,
> component quickly and if you want to provide other capabilities at a later
> point, this isn't a problem. Connecting to specific OS capabilities ("The
> Registry") could be hidden beneath some additional package. Providing some
> sort of mutex capabilities via a database or something could be added on.
> Whatever the needs are, you get there eventually.

Yes.

> 
> But why agonize over all these details now? We can burn those bridges when
> we get to them. :-) Opt for something simple & realizable within our
> lifetimes & maybe it will get done. Isn't that keeping within the whole
> spirit of "Open Source" and "Bizarre Development" :-)

Hehehe

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Fri, 31 May 2002 13:25:31 -0400, Marin David Condic wrote:
> 
> 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.

But if you have a program like say Matlab and there is a Windows, Mac
and Linux version of this program, wouldn't it be nice if people could
use the dumped variables on whatever platform they like to use? I mean
one may be working on something and then he wants to have somebody else
looking at what he has done, he shouldn't be forced to use the same
platform. Or he has Linux on his desktop, but when he travels he has
only Windows on the laptop, why shouldn't he be allowed to work with the
files he has worked on in Linux (and visa versa) without problem?

Preben

Re: A standard package for config files is needed

[Stephen Leake]

tmoran@acm.org writes:

> > ...  I usually used Emacs to edit the files, rather than bother with
> > a spreadsheet or DB program.  But some people did prefer the database
> > program, and having in that format allows people to do DB queries on
> 
>   I'm starting to wonder if everyone is thinking of the same thing when
> they use the term "configuration data".  

Of course not!

> Or are we all on different wavelengths here. I myself am thinking of
> persistent information that is specific to a particular user and
> installation, 

That is certainly one common useage of "config files", and one I
intend to support.

> but not a particular execution (eg, not an individual document in
> the case of a word processing program). 

I want this one. For example, I want one setup for my card game that
make it easy to win (for Fridays), and a different setup that makes it
challenging (for Sundays :).

That's easily accomplished by allowing the config file to be specified
on the command line, and setting up two different icons.

> I also include information that is needed for installation and
> un-installation on a machine, independent of the particular user.

Also a good usage.

> That's a pretty broad definition, including file lists and file
> paths and such text as, for instance, standard signatures. My
> definition also includes settings of flags and semi-constants,
> including structured constants like color palettes or fonts. 

Yes, structured data would be nice. 

My current Windows implementation allows structured data via:

   generic
      type Private_Type is limited private;
      Max_Width : Natural; -- maximum width of Image of Item.
      with function Value (Image : in String) return Private_Type;
   function Read_Private
      (File    : in String;
       Section : in String;
       Keyword : in String;
       Default : in Private_Type)
       return Private_Type;
   -- Return private value associated with Keyword from Section in File. If
   -- Keyword is not found, Default is returned.

and similarly for Write. This means the syntax of the file is _not_
standard for structured types. I'm looking for a better solution; XML
may be it.

> Those are typically not textual and understanding them requires at
> least some understanding of the inner workings of the program. Does
> that jibe with what the term is meaning to other folks?

It matches mine.

Not _everything_ in the config file must be human editable; just some
stuff like the installation directory.

For any particular application, it may be that the registry approach
is better. For another, the config file approach will be better. For
some, maybe a mixture.

In any case, a standard Ada API will help.

-- 
-- Stephe

Re: A standard package for config files is needed

[Stephen Leake]

dennison@telepath.com (Ted Dennison) writes:

> Preben Randhol <randhol+abuse@pvv.org> wrote in message
> news:<slrnaffafb.27t.randhol+abuse@kiuk0156.chembio.ntnu.no>...

> > One thing I'm sitting and thinking about now is if it is possible to
> > make a procedure for storing a record or array and reading this back. I
> > mean a generic procedure.
> 
> It'd be pretty easy, as long as the generic can own the array type.

Yes. My current Ada binding to the Windows ini API has:

   generic
      type Private_Type is limited private;
      Max_Width : Natural; -- maximum width of Image of Item.
      with function Value (Image : in String) return Private_Type;
   function Read_Private
      (File    : in String;
       Section : in String;
       Keyword : in String;
       Default : in Private_Type)
       return Private_Type;
   -- Return private value associated with Keyword from Section in File. If
   -- Keyword is not found, Default is returned.

   generic
      type Private_Type is limited private;
      with function Image (Value : in Private_Type) return String;
   procedure Write_Private
      (File    : in String;
       Section : in String;
       Keyword : in String;
       Item    : in Private_Type);
   -- Write private value Item to Keyord in Section in File.

The problem with this is that the file syntax for structured values is
now controlled by the client, and is thus not standard. Maybe that's
not really a Bad Thing.

> Hmmm. One thing I'm thinking is that this task might be a bit easier
> if the new version of Ada had the following:
> 
>   o  The ability to specify the 'Image routine for user-defined types.
>   o  'Image being defined by default to perform a 'Image on each
> component of a composite type (in order).

We had a thread on this not long ago. The upshot was "just define an
Image function". Getting the compiler to compose it for you is just
not worth it, and also not going to happen.

I may look into creating a variant of Auto_Text_IO that generates
code to write aggregates to strings, rather than files; that would
simplify this issue somewhat.

-- 
-- Stephe

Re: A standard package for config files is needed

[Stephen Leake]

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

> You'll have to forgive us old timers. When we say "ASCII" what we mean is
> "Text". So Unicode in some manner would be (at least in my mind)
> fundamentally the same thing.

To some extent that's true for me as well. But it is an important
distinction. One of the reasons to require ASCII is because you can
use "any old text editor" to fix the config file if you need to. It is
not the case that "any old text editor" can edit unicode; I don't
think Windows notepad can. Emacs can, sometimes, if you're lucky and
the moon is blue :). 

-- 
-- Stephe

Re: A standard package for config files is needed

[Stephen Leake]

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

> The reason is not for efficiency. The reason is that if the file is created
> under program control and is not editable by other means, then you can't
> fill it with corrupt data. Hence you don't have to check it on the way in to
> be sure some bonehead didn't screw up the syntax. It also makes the
> implementation a much simpler thing because there doesn't need to be a
> parser. 

This is an excellent point. However, I'm looking for a compromise; I
believe being able to edit the config file with "any old text editor"
is an important feature. I'm willing to require a _very_ simple syntax
to keep the implementation simple.

-- 
-- Stephe

Re: A standard package for config files is needed

[Stephen Leake]

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

> I just don't see file portability being that big an issue. 

Ok. But others do, so I'm keeping it as a requirement.

> 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. 

That's only one paradigm. I'd like to support as many paradigms as
possible, while keeping the implementation simple.

> But in an embedded, realtime app, I seldom have Text_IO anyway. :-) 

Right; this package will be useless in an embedded app.

> 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.

That's an idea; I'll have to think about it.

> 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.....

another good idea.

-- 
-- Stephe

Re: A standard package for config files is needed

[Ted Dennison]

Robert C. Leif wrote:

> From: Bob Leif
> To: Ted Dennison et al.
> Microsoft, SUN, and IBM are converts. For instance, one can import an
> XML file into Excel. 

If I were susceptable to the "bandwagon" argument, I wouldn't be using Ada.

Re: A standard package for config files is needed

[Darren New]

Stephen Leake wrote:
> I don't think Windows notepad can. 

Of course it can.


-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Ted Dennison et al.
I agree about "bandwagon" argument. However, this time the Ada community
can use it to our advantage. Ada has a good fit with XML; Java does not.
If we go along with XML for the Web, we obviate the need for Java. To
put it bluntly, we get down to two reasonably compatible languages.
Otherwise, Ada is the odd woman left out. 

This is a question of strategic marketing NOT technology. Ada could
probably implement and improve upon most of XML; however, this is NOT
going to happen. Because of market pressures, we have had to interface
to Windows. A totally Ada solution would have been possible; but did not
happen. In fact, the easiest way to work with Windows is R&R CLAW,
because CLAW has the great virtue of being a thick binding, which hides
Windows.  

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Ted Dennison
Sent: Saturday, June 01, 2002 9:39 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed

Robert C. Leif wrote:

> From: Bob Leif
> To: Ted Dennison et al.
> Microsoft, SUN, and IBM are converts. For instance, one can import an
> XML file into Excel. 

If I were susceptable to the "bandwagon" argument, I wouldn't be using
Ada.

Re: A standard package for config files is needed

[Pascal Obry]

"Robert C. Leif" <rleif@rleif.com> writes:

> From: Bob Leif
> To: Ted Dennison et al.
> I agree about "bandwagon" argument. However, this time the Ada community
> can use it to our advantage. Ada has a good fit with XML; Java does not.

I'm completly lost with your arguments about Ada XML and Java !

Can you explain a bit what you have in mind ?

For me there is two different groups here: Languages and a markup language to
structure and exchange data. Both languages (Ada and Java) can use XML and for
me they are on the same groud.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: A standard package for config files is needed

[Preben Randhol]

On Sat, 01 Jun 2002 16:38:48 GMT, Ted Dennison wrote:
> Robert C. Leif wrote:
> 
>> From: Bob Leif To: Ted Dennison et al.  Microsoft, SUN, and IBM are
>> converts. For instance, one can import an XML file into Excel. 
> 
> If I were susceptable to the "bandwagon" argument, I wouldn't be using
> Ada.
> 
And this is also one of the problems with XML. I mean that it is hyped
out of propotions. It is used in all case whether appropriate or not. As
long as you can put on a "XML inside" sticker (well you would get sued
by Intel, but...) your product will gain extra points in the market
no matter how good your program is. One thing I like about XML is that
it is strict. What I don't like is when it is used like this.

<person surname="Randhol" name="Preben" height="XX" weight="XX"\>

in stead of:

<person>
   <surname>Randhol</surname>
   <name>Preben</name>
   <height>XX</height>
   <wieght>XX</weight>
</person>

because it was design to be like the latter not the prior.

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Sat, 1 Jun 2002 10:48:03 -0700, Robert C. Leif wrote:
> This is a question of strategic marketing NOT technology. Ada could
> probably implement and improve upon most of XML; however, this is NOT
> going to happen. Because of market pressures, we have had to interface
> to Windows. A totally Ada solution would have been possible; but did not
> happen. In fact, the easiest way to work with Windows is R&R CLAW,
> because CLAW has the great virtue of being a thick binding, which hides
> Windows.  

Alternatively when GtkAda 2.0 comes (I mean when there are working
binaries for Windows and Linux) it would be even easier to work with
against Windows as you can do the development on Linux ;-)

As for XML and GUI, check:

http://developer.gnome.org/doc/API/libglade/libglade-notes.html#LIBGLADE-BASICS

and

http://libre.act-europe.fr/GtkAda/docs/gtkada_rm_30.html

Is this what you are looking for?

Preben

RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Preben
No. They both use access types, presumably because of the lower level C
code. I like CLAW because it is Ada. I would like tools that translated
XML schemas into Ada data types and Ada data types into XML schemas. An
Ada binding to XForms would be excellent. Unfortunately, neither XForms
nor XML:Fo have a solid implementation. I suspect if the XML developers
had used Ada, the software would be done and reliable. 

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Preben Randhol
Sent: Saturday, June 01, 2002 1:36 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed

On Sat, 1 Jun 2002 10:48:03 -0700, Robert C. Leif wrote:
> This is a question of strategic marketing NOT technology. Ada could
> probably implement and improve upon most of XML; however, this is NOT
> going to happen. Because of market pressures, we have had to interface
> to Windows. A totally Ada solution would have been possible; but did
not
> happen. In fact, the easiest way to work with Windows is R&R CLAW,
> because CLAW has the great virtue of being a thick binding, which
hides
> Windows.  

Alternatively when GtkAda 2.0 comes (I mean when there are working
binaries for Windows and Linux) it would be even easier to work with
against Windows as you can do the development on Linux ;-)

As for XML and GUI, check:

http://developer.gnome.org/doc/API/libglade/libglade-notes.html#LIBGLADE
-BASICS

and

http://libre.act-europe.fr/GtkAda/docs/gtkada_rm_30.html

Is this what you are looking for?

Preben

XML and Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Pascal Obry et al.

Ada and XML both have: range checking, enumerated types, begins and
ends, bounded strings, as well as nesting of types or classes. XML has a
rather verbose import statement that is equivalent to a with and a
renames. The assignment of attributes in XML is similar to the formal
actual notation of Ada. The extendable style language XSL, even has end
if structures. 

Ada syntax is certainly preferable and much more succinct; however, XML
and its schema based family of languages can comfortably coexist with
Ada. I might note that there are parts of XML that Ada could copy. XML
tokens can have both a minimum and a maximum size and specify both a
character set and a pattern for them to be organized. This capacity
exists for all strings and is a super set of the picture clause. Ada can
benefit from these facilities by using XML for the equivalent of
Text_Io.  

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Pascal Obry
Sent: Saturday, June 01, 2002 11:11 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: A standard package for config files is needed


"Robert C. Leif" <rleif@rleif.com> writes:

> From: Bob Leif
> To: Ted Dennison et al.
> I agree about "bandwagon" argument. However, this time the Ada
community
> can use it to our advantage. Ada has a good fit with XML; Java does
not.

I'm completly lost with your arguments about Ada XML and Java !

Can you explain a bit what you have in mind ?

For me there is two different groups here: Languages and a markup
language to
structure and exchange data. Both languages (Ada and Java) can use XML
and for
me they are on the same groud.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: XML and Ada was RE: A standard package for config files is needed

[Pascal Obry]

Ok I see, what you say is that XML is great (I agree), that it is very close
to Ada in syntax and part of the semantic (I agree)... but XML and Ada are
completly different beasts in usage and Java can benefit from XML as much as
Ada can in my point of view.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: XML and Ada was RE: A standard package for config files is needed

[Gerhard Häring]

Robert C. Leif wrote in comp.lang.ada:
> From: Bob Leif
> To: Pascal Obry et al.

Not sure what this means and why you're posting to usenet if this was
meant as a personal email!?

> Ada and XML both have: range checking, enumerated types, begins and
> ends, bounded strings, as well as nesting of types or classes. XML has a
> rather verbose import statement that is equivalent to a with and a
> renames. The assignment of attributes in XML is similar to the formal
> actual notation of Ada. The extendable style language XSL, even has end
> if structures. 

Not considering DSSL and XSLT, which look like a LISP processor in
XML/SGML, XML is _not_ a programming language. It's only a (rather
verbose) way to represent structured data. The main advantage of XML
is that it's standardized, so you can use existing parsers instead of
inventing your own writer and reader for your data formats.

It also has its share of problems. For example parsing it is
relatively inefficient, it takes up a lot of space (bad for embedded
devices, but there are hacks that store XML in a binary format), and
it has IMO relatively poor query capabilities. At least compared to an
RDBMS.

> Ada syntax is certainly preferable and much more succinct; however,
> XML and its schema based family of languages can comfortably coexist
> with Ada. 

Sure. They're different beasts.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: XML and Ada was RE: A standard package for config files is needed

[Darren New]

Gerhard Häring wrote:
> The main advantage of XML
> is that it's standardized, so you can use existing parsers instead of
> inventing your own writer and reader for your data formats.

Actually, I think the other main advantages are that it's pure text (unlike
ASN.1/BER) and you can interleave text and structure (i.e., it has PCDATA
and CDATA). It's also easy to write simple parsers for, given the amount of
power it provides.

If you want to map something to a programming language per se, ASN.1 is a
standardized (really standardized, which I don't think XML is) formatting
system that's much more appropriate.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

RE: XML and Ada

[Robert C. Leif]

From: Bob Leif
To: Pascal Obry et al.
Concerning Java benefiting from anything, I hope not. Since Java is an
inferior technology, whose acceptance is based on marketing and consumer
gullibility, I do not believe that the Ada community has any
responsibility to perform actions that benefit Java's commercial
sponsors.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Pascal Obry
Sent: Saturday, June 01, 2002 11:53 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: XML and Ada was RE: A standard package for config files is
needed


Ok I see, what you say is that XML is great (I agree), that it is very
close
to Ada in syntax and part of the semantic (I agree)... but XML and Ada
are
completly different beasts in usage and Java can benefit from XML as
much as
Ada can in my point of view.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: XML and Ada was RE: A standard package for config files is needed

[Preben Randhol]

On Sun, 02 Jun 2002 15:51:42 GMT, Darren New wrote:
> and CDATA). It's also easy to write simple parsers for, given the amount of
> power it provides.

Not if you want authentication and want to parse the file without
reading all of it into memory first.

Re: XML and Ada was RE: A standard package for config files is needed

[Gerhard Häring]

Preben Randhol wrote in comp.lang.ada:
> On Sun, 02 Jun 2002 15:51:42 GMT, Darren New wrote:
>> and CDATA). It's also easy to write simple parsers for, given the amount of
>> power it provides.
> 
> Not if you want authentication

Authentication?

> and want to parse the file without reading all of it into memory
> first.

Well, yes. Most of the time, SAX is more pain than DOM, especially in
comparison to a simplified DOM API, that exploits language features
instead of just using the least common (language) denominator mandated
by CORBA IDL.

It also forces you to write a state machine (again!), but at least you
only have to override callbacks, not implement the parser itself.

For multi-megabyte data sets, and even with fast parsers like expat, I
still find XML parsing relatively slow.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: XML and Ada was RE: A standard package for config files is needed

[Stephen Leake]

Preben Randhol <randhol+abuse@pvv.org> writes:

> On Sun, 02 Jun 2002 15:51:42 GMT, Darren New wrote:
> > and CDATA). It's also easy to write simple parsers for, given the
> > amount of power it provides.
> 
> Not if you want authentication 

For config files, I don't think we care. But maybe you meant
"validation against the DTD"; we also don't care.

> and want to parse the file without reading all of it into memory
> first.

For config files, we _do_ want to read it all into memory first, or at
least eventually.

-- 
-- Stephe

Re: A standard package for config files is needed

[Robert I. Eachus]

Preben Randhol wrote:

> On the GtkAda list there has been some discussion on making a standard
> package for reading/writing configuration files. As most programs need
> this it would be very nice with a small, platform independant, robust
> but easy to use package.
> 
> Of course one can use XML for something like this, but in most
> applications this would be an overkill. Besides a program shouldn't have to be
> tie in with XMLAda just because of the configuration files. This package
> should be nice for small applications made by student, hobbyists or
> professionals...
> I think this is a package that should be kept as simple as possible and
> easy to use and robust.


Sounds like a good idea, but why all the sound and fury?  This is what 
the IFF (Interchange File Format) was designed to do.  Requiring simple 
programs to understand ALL IFF types would indeed be a heavy burden. 
But IFF is designed so that data in formats your program doesn't 
understand can be skipped over.  One nice thing about .iff files is that 
if you really have to, you can go in with a hex editor and muck about to 
fix a broken file, but reading or writing an IFF file as a byte or 
16-bit word stream is fairly painless.

Basically the way an IFF file works is that every IFF file starts with a 
four byte header.  Almost all IFF files start with 'FORM', 'LIST', or 
'CAT '.  The next four bytes are an unsigned long that tells you the 
number of bytes in the entire object.  One of the two exceptions to the 
above is that some x86 specific IFF files start with 'RIFF' to indicate 
that the byte order of numbers is reversed from standard IFF. (Also some 
MIDI file generators leave out the initial 'FORM' and size and start 
with 'MThd'.)

Of course, the real power of IFF is that the structural types can 
contain a hierarchy of nested objects.  ILBMs are interleaved bit-maps 
for video, 8SVX, AIFF, etc. are audio formats. GIFF is a fairly well 
known image format with a table of 256 colors, etc.  Since the size of 
the object, including nested objects always follows the type, a program 
can skip the data types it doesn't recognize--or want to deal with--and 
select out the data that it does.

How does this differ from XML?  XML formatting is more about schemas, 
and is entirely text based.  In IFF files, 'TEXT' is just another file 
format.  With IFF files you can support all of the UTFx file formats in 
the Unicode (and ISO 10646) standards without raising a sweat.

So IMHO, the way to go is to provide an IFF reader/writer package, have 
it support an 'XML ' data type, and go from there.  Those people who 
only need text support, and don't care about localization can use XML. 
Those who need the whole ball of wax can create IFF files, and support 
XML as a subset.  (I believe that Electonic Arts is still maintaining 
the IFF standard, but the original can be found here: 
http://www.concentric.net/~Bradds/iff.html)

RE: XML and Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Stephen Leake et al.

Please validate against a schema. Schemas have a type structure similar
to Ada's. Hence, validation is useful. DTDs are an old SGML construct,
that will, hopefully, eventually disappear.


-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Stephen Leake
Sent: Sunday, June 02, 2002 3:06 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: XML and Ada was RE: A standard package for config files is
needed

Preben Randhol <randhol+abuse@pvv.org> writes:

> On Sun, 02 Jun 2002 15:51:42 GMT, Darren New wrote:
> > and CDATA). It's also easy to write simple parsers for, given the
> > amount of power it provides.
> 
> Not if you want authentication 

For config files, I don't think we care. But maybe you meant
"validation against the DTD"; we also don't care.

> and want to parse the file without reading all of it into memory
> first.

For config files, we _do_ want to read it all into memory first, or at
least eventually.

-- 
-- Stephe

RE: XML and Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Stephen Leake et al.

Please validate against a schema. Schemas have a type structure similar
to Ada's. Hence, validation is useful. DTDs are an old SGML construct,
that will, hopefully, eventually disappear.


-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Stephen Leake
Sent: Sunday, June 02, 2002 3:06 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: XML and Ada was RE: A standard package for config files is
needed

Preben Randhol <randhol+abuse@pvv.org> writes:

> On Sun, 02 Jun 2002 15:51:42 GMT, Darren New wrote:
> > and CDATA). It's also easy to write simple parsers for, given the
> > amount of power it provides.
> 
> Not if you want authentication 

For config files, I don't think we care. But maybe you meant
"validation against the DTD"; we also don't care.

> and want to parse the file without reading all of it into memory
> first.

For config files, we _do_ want to read it all into memory first, or at
least eventually.

-- 
-- Stephe

Re: XML and Ada was RE: A standard package for config files is needed

[Preben Randhol]

On 2 Jun 2002 20:52:24 GMT, Gerhard H�ring wrote:
> Preben Randhol wrote in comp.lang.ada:
>> On Sun, 02 Jun 2002 15:51:42 GMT, Darren New wrote:
>>> and CDATA). It's also easy to write simple parsers for, given the amount of
>>> power it provides.
>> 
>> Not if you want authentication
> 
> Authentication?

Oops, no, sorry validation I meant.

Preben

Re: XML and Ada was RE: A standard package for config files is needed

[Preben Randhol]

On Sun, 02 Jun 2002 22:06:27 GMT, Stephen Leake wrote:
> 
> For config files, I don't think we care. But maybe you meant
> "validation against the DTD"; we also don't care.

No I was commenting on XML generally.

> For config files, we _do_ want to read it all into memory first, or at
> least eventually.

Yes, but I wasn't referring to that case :-)

Preben

Re: A standard package for config files is needed

[Preben Randhol]

On Mon, 03 Jun 2002 01:00:02 GMT, Robert I. Eachus wrote:
> Sounds like a good idea, but why all the sound and fury?  This is what 
> the IFF (Interchange File Format) was designed to do.  Requiring simple 

Huh? IFF used to be a image file format for Amigas.

> http://www.concentric.net/~Bradds/iff.html)

besides it looks 100 times worse to hand-edit than XML.

Preben

Re: A standard package for config files is needed

[Jacob Sparre Andersen]

Marin David Condic wrote:

> The reason is not for efficiency. The reason is that if the file is created
> under program control and is not editable by other means, then you can't
> fill it with corrupt data.

Optimist.

> Hence you don't have to check it on the way in to
> be sure some bonehead didn't screw up the syntax.

I would certainly appreciate it, if the read data are still
checked for validity.

And I think you're underestimating the kind of boneheads
(like me), who is willing to use `sed` on MS Word documents
(in desperate moments).

> It also makes the
> implementation a much simpler thing because there doesn't need to be a
> parser.

That's a valid point, although the syntax I imagine for a
text based configuration file format is rather trivial to
parse. If it wasn't trivial to parse, it would be likely to
be difficult to write, which would loose the point of having
text based configuration files.

Jacob
-- 
"Sleep is just a cheap substitute for coffee"

Re: A standard package for config files is needed

[Marin David Condic]

Works for me. Its the sorts of things that one would find in the Windows
Registry - information about the installation of the program on a particular
machine, directory paths & files that are normally involved in execution -
or defaults or most recently used (think of how some apps remember that you
were in a particular directory or working with a particular file as the last
thing you were doing.) Or, as you observe, various user default parameters -
colors, fonts, signatures, etc.

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


<tmoran@acm.org> wrote in message
news:TYRJ8.14898$i47.203973743@newssvr14.news.prodigy.com...
>
>   I'm starting to wonder if everyone is thinking of the same thing when
> they use the term "configuration data".  Or are we all on different
> wavelengths here.  I myself am thinking of persistent information that
> is specific to a particular user and installation, but not a particular
> execution (eg, not an individual document in the case of a word
> processing program).  I also include information that is needed for
> installation and un-installation on a machine, independent of the
> particular user.  That's a pretty broad definition, including file
> lists and file paths and such text as, for instance, standard
> signatures.  My definition also includes settings of flags and
> semi-constants, including structured constants like color palettes or
> fonts.  Those are typically not textual and understanding them requires
> at least some understanding of the inner workings of the program.  Does
> that jibe with what the term is meaning to other folks?

Re: A standard package for config files is needed

[Marin David Condic]

If this is how you are using a "Configuration" file then I suggest it is no
longer a "Configuration" file and is instead a "Data" file for your
application. What I (and maybe others) are thinking of is initialization and
user preference data - stuff that is relatively small and specific to a
platform, installation and user. I cannot recall any time in my experience
with using computers where I have wanted to drag this from one machine to
another machine of totally different character. Even if I did - its in the
nature of the beast that it is relatively *small* and shouldn't take hours
to recreate.

Besides, as I said elsewhere, you have no guarantees with Ada that any
*data* files you write are going to be portable across different platforms
and it would seem that the situations you suggest would come up *far* more
often with normal data files. So should we never use any of the Ada I/O
packages? Based on the way I have seen programs used over the years, I just
don't imagine that "configuration" information is going to need to port from
one platform to another often enough that it is worth worrying about. I'd
opt for simplicity and, if done right, the base class could be overriden and
enhanced to support whatever special needs anybody could dream up. I'd take
bets that if there was a binary storage of configuration data that most
people would not bother to override it with an ASCII implementation - but if
it was desirable, it would be an easy extension.

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


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnafhkb6.2qc.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> But if you have a program like say Matlab and there is a Windows, Mac
> and Linux version of this program, wouldn't it be nice if people could
> use the dumped variables on whatever platform they like to use? I mean
> one may be working on something and then he wants to have somebody else
> looking at what he has done, he shouldn't be forced to use the same
> platform. Or he has Linux on his desktop, but when he travels he has
> only Windows on the laptop, why shouldn't he be allowed to work with the
> files he has worked on in Linux (and visa versa) without problem?
>
> Preben

Re: XML and Ada was RE: A standard package for config files is needed

[Marin David Condic]

I agree that DTDs are not nearly so wonderful as an XSL schema. I wouldn't
see any reason to use DTDs when XSL provides a much more powerful and far
less clumsy way of expressing what constitutes valid data.

However, in the context of the proposed config files, there's a bit of a
problem. AFAIK, there isn't any Ada implementation of either a DTD or XSL
"validator". There is an XML DOM - which is interesting and something that
can be leveraged. But I don't believe it has any capability of applying an
XSL schema (or any other validation means) against its inputs. It would be
an interesting capability to add...

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


"Robert C. Leif" <rleif@rleif.com> wrote in message
news:mailman.1023070922.31368.comp.lang.ada@ada.eu.org...
>
> Please validate against a schema. Schemas have a type structure similar
> to Ada's. Hence, validation is useful. DTDs are an old SGML construct,
> that will, hopefully, eventually disappear.
>

Re: A standard package for config files is needed

[Darren New]

Preben Randhol wrote:
> 
> On Mon, 03 Jun 2002 01:00:02 GMT, Robert I. Eachus wrote:
> > Sounds like a good idea, but why all the sound and fury?  This is what
> > the IFF (Interchange File Format) was designed to do.  Requiring simple
> 
> Huh? IFF used to be a image file format for Amigas.

No. IFF is Interchange File Format. It's the basis of lots of stuff,
including PNG image files (altho PNG changed it around a little bit in
interesting and good ways, but used the same concepts) and I think TIFF uses
the same concepts as well.

Most all the file formats on the Amiga were IFF, including sound, movies,
images, word processor docs, 3D vector graphics, raytracer inputs, etc.
There were programs to (for example) extract the images out of word
processor documents in spite of the program not knowing the word processor
format.

The Amiga image formats were specifically IFF/ILBM - Interchange File
Format, InterLaced BitMap.
 
> besides it looks 100 times worse to hand-edit than XML.

Yes. It's a binary format with lots of length counts in it. I can't imagine
hand-editting it.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: A standard package for config files is needed

[Darren New]

Darren New wrote:
> No. IFF is Interchange File Format. It's the basis of lots of stuff,
> including PNG image files (altho PNG changed it around a little bit in
> interesting and good ways, but used the same concepts) and I think TIFF uses
> the same concepts as well.

Before I get flamed, let me rephrase that.

PNG and TIFF both use the same tagged-length nested kind of structure,
meaning that it's considered a generally pretty good idea. They may have
been inspired by IFF's design.

I did not mean to imply that IFF per se was actually the basis of PNG or
TIFF, merely that the basic concepts are similar. And I like how PNG
actually tells you whether it's safe to ignore subblocks. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: XML and Ada was RE: A standard package for config files is needed

[SteveD]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:adftvr$1pr$1@nh.pace.co.uk...
> I agree that DTDs are not nearly so wonderful as an XSL schema. I wouldn't
> see any reason to use DTDs when XSL provides a much more powerful and far
> less clumsy way of expressing what constitutes valid data.
>
> However, in the context of the proposed config files, there's a bit of a
> problem. AFAIK, there isn't any Ada implementation of either a DTD or XSL
> "validator". There is an XML DOM - which is interesting and something that
> can be leveraged. But I don't believe it has any capability of applying an
> XSL schema (or any other validation means) against its inputs. It would be
> an interesting capability to add...

XMLAda does include a DTD validator.  I've tested it with a small sample.  I
did have to change a couple of lines in one of the source files to have it
work, I have already submitted the changes, but haven't seen them show up in
a new version (I think GPS is taking a higher precident).

SteveD

>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
>
>
> "Robert C. Leif" <rleif@rleif.com> wrote in message
> news:mailman.1023070922.31368.comp.lang.ada@ada.eu.org...
> >
> > Please validate against a schema. Schemas have a type structure similar
> > to Ada's. Hence, validation is useful. DTDs are an old SGML construct,
> > that will, hopefully, eventually disappear.
> >
>
>
>

Re: A standard package for config files is needed

[Preben Randhol]

On Mon, 3 Jun 2002 09:23:10 -0400, Marin David Condic wrote:
> If this is how you are using a "Configuration" file then I suggest it is no
> longer a "Configuration" file and is instead a "Data" file for your

You started with saying that streams where good for dumping a lot of
variables if I recall correctly. I would also define it as a Data file.

> application. What I (and maybe others) are thinking of is initialization and
> user preference data - stuff that is relatively small and specific to a
> platform, installation and user. I cannot recall any time in my experience
> with using computers where I have wanted to drag this from one machine to
> another machine of totally different character. Even if I did - its in the
> nature of the beast that it is relatively *small* and shouldn't take hours
> to recreate.

Well perhaps because you couldn't? I mean it hasn't been usual that one
can use the same program on several platforms. Now it is time to think
in these terms IMHO. 

Well whether it is small or not doesn't matter. Say you are setting up
the program to be used by 400 kids in a school and you have about 200
machine whith different platforms.

or a more realistic example. Say you have configured about 10
applications (or more) so that they are more easy to use. Now you want
to set this exact same setup up for some other people. It is far easier
to just copy the files than have to reconfigure them on each machine.

With Vim (and Emacs) which works on a lot of platform you set up a lot
of files you wants it to load so that you have more features. You can
copy them without problems between platforms.

Preben

Re: XML and Ada was RE: A standard package for config files is needed

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
: From: Bob Leif
: To: Stephen Leake et al.
: 
: Please validate against a schema. Schemas have a type structure similar
: to Ada's. Hence, validation is useful. DTDs are an old SGML construct,
: that will, hopefully, eventually disappear.

Doubt it, and Goldfarbs comments on this seem to indicate, at
least to me, that DTDs have and will have very good uses. Why put
everything about data in schemas and not in applications? ONly
reason I can think of is lack of (human) communication of
data exchange parties. That is: Write a good DTD indicating
what you expect to be in the data and make this DTD known to
the other end. Then write appropritate programs.
Note also that there is a convention based
way to put type information into attributes. It's just not as
standardised as schemas might be.

I can't think of a software library that automatically creates composed
data objects of some (how?) automatically created type by reading an
input stream that follows a schema. Somewhere I have to decide what
information to expect... Am I missing something?

-- Georg

Re: XML and Ada was RE: A standard package for config files is needed

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
:  But maybe you meant
: "validation against the DTD"; we also don't care.

I think this is a mistake.  A DTD is a _very_ good opportunity
to think about data, even if this seem like overkill for "mere"
config files. And how fault tolerant is the configuration process?
(Speed shouldn't be an issue here, or should it?)

-- Georg

RE: XML and Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Georg Bauhaus et al.
I think of a schema as the data types in an Ada specification. The XML
document data has to be type compliant with the schema. A second schema
can make subtypes from or extend types present in an imported (withed)
schema. I admit that I have an Ada mind set. 

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Georg Bauhaus
Sent: Tuesday, June 04, 2002 11:49 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: XML and Ada was RE: A standard package for config files is
needed

Robert C. Leif <rleif@rleif.com> wrote:
: From: Bob Leif
: To: Stephen Leake et al.
: 
: Please validate against a schema. Schemas have a type structure
similar
: to Ada's. Hence, validation is useful. DTDs are an old SGML construct,
: that will, hopefully, eventually disappear.

Doubt it, and Goldfarbs comments on this seem to indicate, at
least to me, that DTDs have and will have very good uses. Why put
everything about data in schemas and not in applications? ONly
reason I can think of is lack of (human) communication of
data exchange parties. That is: Write a good DTD indicating
what you expect to be in the data and make this DTD known to
the other end. Then write appropritate programs.
Note also that there is a convention based
way to put type information into attributes. It's just not as
standardised as schemas might be.

I can't think of a software library that automatically creates composed
data objects of some (how?) automatically created type by reading an
input stream that follows a schema. Somewhere I have to decide what
information to expect... Am I missing something?

-- Georg

Re: XML and Ada was RE: A standard package for config files is needed

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
: I think of a schema as the data types in an Ada specification. The XML
: document data has to be type compliant with the schema. A second schema
: can make subtypes from or extend types present in an imported (withed)
: schema. I admit that I have an Ada mind set. 

Hmm, would that be more than a schema based XML syntax for the
creation of Ada syntax based definitions of the same data types?

I found this in The SGML Handbook:
"The net result of this design [data as text] is that
an application is free to define its own semantics and
the representation of its data types. The SGML parser can
guarantee that the user's specified attribute values will meet
the applications's lvength and alphabe restrictions, so they
will fit into the application's buffers and be valid input
to the application's routines that convert them to internal
representations.  The application retains the responsibility of
determining whether the converted values satisfy its semantic
constraints.[4]
 "[4] There is no intention here to suggest that standardization
of processing semantics and data type representations would
not be a good thing--only that it should not be the province
of SGML.  Introducing semantic standards into SGML would only
serve to limit the potential processing of a document, as a
single semantic standard is no more likely to be optimal for
all pllications than a single programming language."

What would be the result in case of fpt calculations, e.g.?
If, by the schemata, your data tell me to consider X as a float
with constraints Y, would there be a requirement to use these
constraints in my program? Or would I be free to add precision
by asking the compiler for a higher precision?

-- Georg

RE: XML and Ada was RE: A standard package for config files is needed

[Robert C. Leif]

From: Bob Leif
To: Georg Bauhaus et al.

My comments were specifically directed to XML schema. Therefore, the
SGML handbook is only of historical interest. 

As for floating point types or others used in calculations, it depends
who created the schema. If the schema is created by an Ada programmer,
one obvious simplification is to make the Ada and XML data types as
close as possible. As for further restricting (subtyping) of the Ada
data types, this depends entirely on the application. However, most of
the time, the simplest approach is to initially create a data type to
meet all of one's requirements. 

If I obtain an XML schema that has not been strongly typed, wherever
possible, I create the equivalent of Ada subtypes with explicit ranges. 

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Georg Bauhaus
Sent: Thursday, June 06, 2002 7:15 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: XML and Ada was RE: A standard package for config files is
needed

Robert C. Leif <rleif@rleif.com> wrote:
: I think of a schema as the data types in an Ada specification. The XML
: document data has to be type compliant with the schema. A second
schema
: can make subtypes from or extend types present in an imported (withed)
: schema. I admit that I have an Ada mind set. 

Hmm, would that be more than a schema based XML syntax for the
creation of Ada syntax based definitions of the same data types?

I found this in The SGML Handbook:
"The net result of this design [data as text] is that
an application is free to define its own semantics and
the representation of its data types. The SGML parser can
guarantee that the user's specified attribute values will meet
the applications's lvength and alphabe restrictions, so they
will fit into the application's buffers and be valid input
to the application's routines that convert them to internal
representations.  The application retains the responsibility of
determining whether the converted values satisfy its semantic
constraints.[4]
 "[4] There is no intention here to suggest that standardization
of processing semantics and data type representations would
not be a good thing--only that it should not be the province
of SGML.  Introducing semantic standards into SGML would only
serve to limit the potential processing of a document, as a
single semantic standard is no more likely to be optimal for
all pllications than a single programming language."

What would be the result in case of fpt calculations, e.g.?
If, by the schemata, your data tell me to consider X as a float
with constraints Y, would there be a requirement to use these
constraints in my program? Or would I be free to add precision
by asking the compiler for a higher precision?

-- Georg

Re: XML and Ada was RE: A standard package for config files is needed

[Georg Bauhaus]

Robert C. Leif <rleif@rleif.com> wrote:
: My comments were specifically directed to XML schema. Therefore, the
: SGML handbook is only of historical interest. 

Uhm, I think this is a misunderstanding (and a big one :-).
(The SGML Handbook, for those who haven't seen it, is much
like the combination of the Ada Annotated RM + Rationale,
with respect to ISO 8879 (SGML).)

XML ist still just a subset of SGML, and schema definitions 
can (therefore) be expressed in SGML, but they need not even
be expressed in XML. More importantly (and this
is why I've found the quote interesting): some of the intentions
behind schemas (more semantic information about document data
element types) are not an entirely new argument. (The author (Goldfarb)
is, I think you know, one of the two authors of The XML Handbook.)

: If I obtain an XML schema that has not been strongly typed, wherever
: possible, I create the equivalent of Ada subtypes with explicit ranges. 

This is what I wanted to point out in the quote. While I agree
that it would be nice, if at all possible, to have a consensually
defined data type (using a schema expressed in XML) independent
of a programming language, I would want this as part of the
minimal requirements section of some document, and then use the
best language techniques to implement software fulfilling these
requirements.

-- Georg

Re: XML and Ada was RE: A standard package for config files is needed

[Stephen Leake]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Stephen Leake <stephen_leake@acm.org> wrote:
> :  But maybe you meant
> : "validation against the DTD"; we also don't care.
> 
> I think this is a mistake.  A DTD is a _very_ good opportunity
> to think about data, even if this seem like overkill for "mere"
> config files. And how fault tolerant is the configuration process?
> (Speed shouldn't be an issue here, or should it?)

Ok. Good points. 

Speed should _not_ be an issue. That belongs in the requirements.

I think my problem is I have no idea how to go about using a DTD. In
particular, the Glib.XML package does _not_ support validation.

I guess I have some homework to do ...

-- 
-- Stephe

Re: A standard package for config files is needed

[Stephen Leake]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> Sounds like a good idea, but why all the sound and fury?  

Well, I don't think this discussion counts as "sound and fury" :). It
started with "anybody have a good config file package".

> This is what the IFF (Interchange File Format) was designed to do.
> Requiring simple programs to understand ALL IFF types would indeed
> be a heavy burden. 

I guess that's similar to picking XML as the Config File format, but
only using a subset.

> But IFF is designed so that data in formats your program doesn't
> understand can be skipped over. One nice thing about .iff files is
> that if you really have to, you can go in with a hex editor and muck
> about to fix a broken file, but reading or writing an IFF file as a
> byte or 16-bit word stream is fairly painless.

Well, if there is no subset of IFF that is easily edited in "any old
text editor", then we can't use it; that's a prime requirement.

> <snip more description>

It sounds like IFF is "merely" a top-layer grouping format; the
details of any particular object are specified elsewhere. So we'd have
the first four bytes be "CONF" (or "TEXT"), and IFF would have nothing
to say about the rest of the file. Not much help.

> How does this differ from XML?  XML formatting is more about schemas,
> and is entirely text based.  In IFF files, 'TEXT' is just another file
> format.  With IFF files you can support all of the UTFx file formats
> in the Unicode (and ISO 10646) standards without raising a sweat.

Well, somebody has to implement it! Is there an Open Source/Free
Software implementation somewhere?

> So IMHO, the way to go is to provide an IFF reader/writer package,
> have it support an 'XML ' data type, and go from there. Those people
> who only need text support, and don't care about localization can
> use XML. Those who need the whole ball of wax can create IFF files,
> and support XML as a subset. 

If XML is a subset, this is way more power than we need.

> (I believe that Electonic Arts is still maintaining the IFF
> standard, but the original can be found here:
> http://www.concentric.net/~Bradds/iff.html)

The document mentions some "public domain" C source code, but I don't
see them on the web site.

-- 
-- Stephe

Re: XML and Ada was RE: A standard package for config files is needed

[Eric G. Miller]

In <wkzny4rzl7.fsf@acm.org>, Stephen Leake wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
>> Stephen Leake <stephen_leake@acm.org> wrote:
>> :  But maybe you meant
>> : "validation against the DTD"; we also don't care.
>> 
>> I think this is a mistake.  A DTD is a _very_ good opportunity
>> to think about data, even if this seem like overkill for "mere"
>> config files. And how fault tolerant is the configuration process?
>> (Speed shouldn't be an issue here, or should it?)
> 
> Ok. Good points. 
> 
> Speed should _not_ be an issue. That belongs in the requirements.
> 
> I think my problem is I have no idea how to go about using a DTD. In
> particular, the Glib.XML package does _not_ support validation.

That seems odd, since libxml2 supports DTD validation (they're in the
process of adding XML schemas...).  But, I'm not familiar with the
Glib binding (I imagine a GLIB2 binding would bring in libxml2...).
Seems it'd be useful to have an independent binding for libxml2 so
you don't have to bring glib into the picture if you don't need/want
it and also get full access to all the functionality (I think GLIB
just implements/uses a small subset).

Re: XML and Ada was RE: A standard package for config files is needed

[Stephen Leake]

"Eric G. Miller" <egm2@jps-nospam.net> writes:

> >> Stephen Leake <stephen_leake@acm.org> wrote:
> > I think my problem is I have no idea how to go about using a DTD. In
> > particular, the Glib.XML package does _not_ support validation.
> 
> That seems odd, since libxml2 supports DTD validation (they're in the
> process of adding XML schemas...).  But, I'm not familiar with the
> Glib binding

Glib.XML from GtkAda is not a binding, it's a simple implementation of
a very small subset of XML.

> (I imagine a GLIB2 binding would bring in libxml2...). Seems it'd be
> useful to have an independent binding for libxml2 so you don't have
> to bring glib into the picture if you don't need/want it and also
> get full access to all the functionality (I think GLIB just
> implements/uses a small subset).

Sounds like a good idea. Are you volunteering ? :).

-- 
-- Stephe

Re: XML and Ada was RE: A standard package for config files is needed

[Eric G. Miller]

In <wk4rgbgvrg.fsf@acm.org>, Stephen Leake wrote:

>> (I imagine a GLIB2 binding would bring in libxml2...). Seems it'd be
>> useful to have an independent binding for libxml2 so you don't have
>> to bring glib into the picture if you don't need/want it and also
>> get full access to all the functionality (I think GLIB just
>> implements/uses a small subset).
> 
> Sounds like a good idea. Are you volunteering ? :).

If I was a more competent Ada programmer, I might.  The SAX interface
looks a little dodgy to me.  It's also a pretty large API...