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:30:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fr.usenet-edu.net!usenet-edu.net!proxad.net!proxad.net!216.166.61.5.MISMATCH!border1.nntp.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!bin8.nnrp.aus1.giganews.com.POSTED!not-for-mail Sender: Stephe@TAKVER Newsgroups: comp.lang.ada Subject: Re: config files proposal References: <3CFA8E42.B7844253@san.rr.com> <4519e058.0206030656.34c424ff@posting.google.com> 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-YxWUOXx+XJI8vH9J9rX8S3EU8WkV5gZPA9CyNE= NNTP-Posting-Date: Sun, 09 Jun 2002 15:29:42 CDT Organization: Giganews.Com - Premium News Outsourcing X-Trace: sv3-GnhfP9jtr81vbS9b+Xs/F8jS4Ab0IWIPQbhjr7xXAXnxSOpRMIYxmPun9fVshZ4sQE9G2OJ+u1J0v4W!ISwMCqZt24GNTDRWPMQXqLYwf4myPs7heRGpXasmXS3YzivzyOv3fQ== 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:29:42 GMT Xref: archiver1.google.com comp.lang.ada:25619 Date: 2002-06-09T20:29:42+00:00 List-Id: dennison@telepath.com (Ted Dennison) writes: > 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. Perhaps. The config file API allows the application to specify a search path (possibly two; one read-only). It's up to the application how much control to pass on to the user. I'd like the config file package to support the widest range of scenarios (even ones I don't like :). > 2) There will be only one config file per system. Not true. > 3) The facility will be dependent on the very system-dependant > feature of directory search paths. No need for this to be system dependent. In my draft spec, I represent a search path by a list of strings. In any case, the body of a config file implementation may very well be system dependent; Ada.Text_IO is probably not up to implementing this spec. > I don't like the first two ideas at all, since they needlessly > restrict the funtionality. Right; that's why they aren't there :). > 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. Please check back when I post the draft spec; that will probably make it clearer. > Clients of the facility should be able to read and write > configurations to and from the directories and file names of their > choice. Yes, that's true. But we also have to handle the situations that Darren is bringing up. An application should be able to use both system-wide and user-specific config files. Users should _not_ be able to edit system-wide config files, but they _should_ be able to read them, as defaults that are overridden by their user-specific files. > 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. Well, using GNAT.Directory_Operations makes it portable in one sense. 100 % portable across operating systems is not possible. Some sort of accomodation must be made for file and directory access on different operating systems. > 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 is certainly undesirable. But I think that as long as terms like "directory" and "file" are well-defined, we should be ok. Note that the MAC tends to blur these a little; a "file" has a "resource-fork" and a "data-fork" (I think those are the right terms :). > 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. Yes. The config-file API is intended to be completely portable. > > > 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. :-) As has been discussed before on cla, there are ways around this. > > > 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". Exactly. > Presumably this is just a first cut to get the "easy ones" ironed > out, before we start to agree on a file format. Right? Yes. > If so, a lot of this discussion will be rendered moot when the file > format is decided upon. Yes. > > 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. That's what I was trying to say. There needs to be more than two files in the chain, but only one (the first one?) is writeable. > 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. Yes, that's what I'd like to support. > > > 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. Yes, it is. > > 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. I'd like to have a general "binary data - not human editable" data type. Maybe with an Ada Streams interface? -- -- Stephe