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-03 07:56:09 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dennison@telepath.com (Ted Dennison) Newsgroups: comp.lang.ada Subject: Re: config files proposal Date: 3 Jun 2002 07:56:09 -0700 Organization: http://groups.google.com/ Message-ID: <4519e058.0206030656.34c424ff@posting.google.com> References: <3CFA8E42.B7844253@san.rr.com> NNTP-Posting-Host: 65.115.221.98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1023116169 11527 127.0.0.1 (3 Jun 2002 14:56:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 3 Jun 2002 14:56:09 GMT Xref: archiver1.google.com comp.lang.ada:25257 Date: 2002-06-03T14:56:09+00:00 List-Id: Stephen Leake wrote in message news:... > Darren New writes: > > You need to specify where a file is written in the path. (API#6) > > apparently only talks about reading files. > > It should be written where it is found; I'll add that. Hmm, special > case if it is a new file; write it to the first directory in the > search path. Perhaps I'm misunderstanding, but this sounds to me like you are saying: 1) Users have very little control over where their config files get written to. 2) There will be only one config file per system. 3) The facility will be dependent on the very system-dependant feature of directory search paths. I don't like the first two ideas at all, since they needlessly restrict the funtionality. I could easily see loads of people who would otherwise love to use the facility, forced to roll their own due to problems with 1 and 2. Clients of the facility should be able to read and write configurations to and from the directories and file names of their choice. The third issue I think requires a good deal of discussion before being accepted. For one thing, it will prevent anyone from making a portable implementation of the config file facility. It should also be noted that if this facility's behavior depends on an implementation-defined facility, then you are basicly saying that (part of) this facility's behavior is implementation-defined. That in turn means programs that use this facility are going to have portability issues. In my mind, that's more serious than having non-portable config files. > > FF #3 I would disagree with. It limits having large items in the > > config file format. > > Only if there is a maximum line length. I guess some text editors > might impose one, but Ada.Text_IO doesn't. Since it requires that the user supply a fixed-length buffer, Ada.Text_IO effectively *does* impose a limit. It just lets you decide what that limit is. :-) > > Making key/value pairs terminated by a newline is specifying the > > implementation. I'd disagree with this statement. It is (partially) specifying a file format, but in no way specifies how the config file facility implements it. The file format *has* to be part of the specification, it can't be left as an "implementation detail". Presumably this is just a first cut to get the "easy ones" ironed out, before we start to agree on a file format. Right? If so, a lot of this discussion will be rendered moot when the file format is decided upon. > > Question: Are keys case-sensitive? > > Good point. I think I'll go with the Ada identifier model and say > "no". I agree wholeheartedly, for the same reason. > I'm not sure what your question is. Oh, I see; you want me to request > key "foo", and if not found in ~/.bashrc then look in /etc/bashrc to > find "foo". Hmm. > > I guess we could add an "append_read_only" operation, that would read > in a second file, and store it in a separate read-only tree. I like > that. Perhaps it would be better to allow for some kind of "chaining" of configuration objects? That way items not found in the first configuration might be found in later ones. In most of my projects that use configuration files, there are a set of hard-coded defaults for all configuration values. That way if no config files exist, we still have a reasonable set of defaults defined. A client creating a "default" configuration object that is loaded with values from the program at initialization time and chained on the back would be one way of implementing this. > > Question: Is the file closed (w.r.t. the OS) between the end of the > > read and the start of the write? > > Yes. Actually, I think the file is OS closed at the end of Open, after > the data is read in. *That* sounds like an implementation detail to me. Its a good idea perhaps, but still an implementation detail. > I'm planning on renaming the file to a backup name before writing it, > for glitch protection. Ditto > base64 would be good for values that don't need to be user editable. I > guess persistent storage for a large object (whether it is composite > or not) could be supported that way. I'm not clear why that would be > in a typical "config file". Hmm, maybe a pixel bitmap for an icon? Motif's UIL did these as text. You define the colormap for each ASCII character, then use the defined ASCII characters to draw the bitmap. In the text buffer it looked a bit like ASCII art. The only big drawback I saw was that the "art" value is destroyed if your bitmap gets wider than your text editor. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html