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 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-09 13:55:01 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newsfeed-west.nntpserver.com!hub1.meganetnews.com!nntpserver.com!DirecTVinternet!DirecTV-DSL!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!feed.newsfeeds.com!cyclone-sf.pbi.net!151.164.30.35!cyclone.swbell.net!easynews!nntp2.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!bin5.nnrp.aus1.giganews.com.POSTED!not-for-mail Sender: Stephe@TAKVER Newsgroups: comp.lang.ada Subject: Re: config files proposal References: From: Stephen Leake Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-GC-Trace: gv1-DA5914ZzTDoXjXsEKJ6W58cLHBdz6NIR+PJSX0= NNTP-Posting-Date: Sun, 09 Jun 2002 15:54:45 CDT Organization: Giganews.Com - Premium News Outsourcing X-Trace: sv3-7kdr8MzASr6/dNoaPst7+WsYhxHtytBK6iIeOiKECEQGWXKHQoiGVJh0r11QFn4Yr4fLny5kXiR1mfn!gVyMRfdbY5C3vKMufZnBrOO5U4X+xcIsWB6xNzu0EKaal18fmJgjzTg= X-Complaints-To: abuse@comcast.com X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly Date: Sun, 09 Jun 2002 20:54:45 GMT Xref: archiver1.google.com comp.lang.ada:25622 Date: 2002-06-09T20:54:45+00:00 List-Id: antonio_duran@hotmail.com (Antonio Duran) writes: > 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. True. > 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. Good point; I hadn't thought of that. I think this makes XML a better idea; we can allow for a "comment" tag that is saved in the memory image, and written back out. > When config file gets complicated enough one must write an > application to handle it (eg. Comanche to mantain Apache config > files). Yes. We need to support both modes of operation. > 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. Yes, but there's no reason config files have to have the same restrictions. > 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?. You could use them that way. In this particular case, the Gnu 'get_text' facility is probably better. But if you have only a few messages, and also other things to configure, a config file would be a good place to do this. > 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. Ok, thanks for your input. But, I'd like you to think again :). Can you come up with any situation in which you would use Wide_String keys? Do you use Wide_String for anything in your applications? Here in the US, it's easy to think "ASCII solves all problems"; I'd appreciate some input from someone for whom that is not true. > 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. Yes, I intend to support this. Please check the draft spec when I post it, to see if it meets these needs. > 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?. only the defaults; API req 7 allows the application to override these defaults. > 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?). The point was that some applications (typically from Gnu and/or Linux) put config files in very standard places, like /usr/local/share. So this default should be compiled in on Linux. However, other applications will want to specify thier own places for config files, so that has to be allowed as well. > 5. Regarding to the file syntax, long time ago I worked on a system > that runs on CAIS (Common APSE Interface Set). > > 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. And it's really only readable for people who know Ada; we'd like this to be useful to a wider audience. -- -- Stephe