From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7624df5e57d09688 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-04 08:41:30 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: antonio_duran@hotmail.com (Antonio Duran) Newsgroups: comp.lang.ada Subject: Re: config files proposal Date: 4 Jun 2002 08:41:30 -0700 Organization: http://groups.google.com/ Message-ID: References: NNTP-Posting-Host: 192.101.1.126 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1023205290 17810 127.0.0.1 (4 Jun 2002 15:41:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 4 Jun 2002 15:41:30 GMT Xref: archiver1.google.com comp.lang.ada:25308 Date: 2002-06-04T15:41:30+00:00 List-Id: Stephen Leake wrote in message news:... > I've posted a summary of the requirements and options for a config > file standard, at > http://users.erols.com/leakstan/Stephe/Ada/config_files.html > > I'm going to experiment with an XML implementation before I post a > draft spec; I suspect using XML for the file format will have an > impact on the spec. If I find XML too complex, I'm leaning towards the > Java property style. > > Please comment on the requirements. > > Please don't say "just use the registry"; let's take that discussion > as settled :). The consensus is we need both the registry and a > simpler config file. > > I'm on vacation starting Tuesday (back the following Monday), so I > won't be responding to comments till then. I'll try to catch up on all > of this thread when I get back, but feel free to send me email > directly at stephen_leake@acm.org. In relation to config files there are some points that I would like to comment. I don't read the entire thread so please, forgive me if some or all of them were previously discussed. 1. In my experience, most of the time, config files are writen, edited or modified by humans and read and interpreted by programs. With this in mind, in my modest opinion, the importance of having an API for writing to config files is secondary. What is important is having the means that allow a human user to understand what is in the config file. Configuration tasks are simpler if the config file is commented and handling comments is difficult if you use an API call to write to the file. When config file gets complicated enough one must write an application to handle it (eg. Comanche to mantain Apache config files). 2. Seems that there is a consensus in that a config file must store key/value(s) pairs. I don't understand the requirement to use Wide_String for keys. I'm from Spain and I usually write in Spanish but when programming in Ada I must adhere to the Ada syntax, I can't write Ada identifiers that are syntactically correct spanish words and the Ada reserved words are english words. Supporting Wide_String could be a cool feature for, for example, mantaining localized messages in different languages, however: is this the purpose of config files?. I think the purpose of config files is to provide parameters to a program or application and not to be used as a repository for localized versions of program messages. Of course, they could be used in that way. I suggest that keys in config file meet the Ada syntax for identifier and be case-insensitive. 3. I think that is important to handle more than one config file in a single program. From my point of view, one of the most important drawbacks of layouts such as the Windows Registry is that everything is on a single place so applications that can access to a single part can also write other parts. In complicated apps it could be desirable to mantain a set of different config files one for each part of the application. The ability for handling multiple config files in a single program should be a requirement for a config file handling package. 4. I don't understand very well the implications of "... specified by generic parameter at compile time ..." (API req. 5). Does this mean that the name or the path of the file must be hard coded?. If so I think we've missed totally the point (should I recompile each time I change the name or location of the config file?). 5. Regarding to the file syntax, long time ago I worked on a system that runs on CAIS (Common APSE Interface Set). CAIS contains a List Management package that provides great power for handling parameter lists and those lists have a human readable text representation. That text representation is, from my point of view, more Ada like and could be used as a base syntax for config files. The example provided in the Stephen requirements page would be (comments were not allowed in CAIS Lists) -- Config file TBD. ( -- ServerLayout Section. ServerLayout => ( Identifier => "Default Layout", Screen => ("Default Screen", 0, 0), InputDevice => ( "Generic Keyboard", "Configured Mouse", "Generic Mouse" ), Display => ( Depth => 1, Modes => ( (Width => 16#400#, Height => 768), (Width => 800, Height => 600) -- New mode added. ) ) ) -- End of ServerLayout section. ) -- End of config file TBD There are, however, some drawbacks in this representation: - A escaping schema is needed for unprintable characters in strings (?). - Nested '(' and ')' would add a high degree of complexity for the human user/reader. Antonio Duran