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-02 15:16:18 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!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> 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 NNTP-Posting-Date: Sun, 02 Jun 2002 17:16:00 CDT Organization: Giganews.Com - Premium News Outsourcing X-Trace: sv3-Gp9RIzrAOBQTLjWkGQEJh8+mY/WetIj+D5Mx/D5CVTuNoSmVfPspSAoNz6MAXuMOffKI+w2TfDYEVwu!7VbpU7G6I2QFCAUCwoR6MnL6g2Q8TA75o/3p6hRki3M= X-Complaints-To: abuse@comcast.com X-DMCA-Complaints-To: abuse@comcast.com 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, 02 Jun 2002 22:16:00 GMT Xref: archiver1.google.com comp.lang.ada:25223 Date: 2002-06-02T22:16:00+00:00 List-Id: Darren New writes: > Stephen Leake wrote: > > http://users.erols.com/leakstan/Stephe/Ada/config_files.html > > I would suggest using Wide_String for keys. (API#8) Hmm. Good idea. I'm not clear why I limited that. But I'm glad I made it specific, so you could point out it was wrong :). > 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. > FF #1 has to deal with the differences between systems anyway. > Character sets, newlines, etc. Or at least mention what you mean. > That is, file format #1 kind of conflicts with file format #2, if > Text_IO writing on one system isn't readable on another. Good point. I guess I need to say "files can be copied with normal system-dependent changes (such as line endings)." > 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. > Making key/value pairs terminated by a newline is specifying the > implementation. Yes, but that's what FF is about anyway. > It doesn't make any sense to do such a thing in XML, for example. True. > Perhaps starting continuation lines with a space as is done in RFC > 822 headers would make more sense. Well, I guess there are many ways to deal with mult-line formats. > In addition, API#15 conflicts with this requirement. I don't see how. API#15 says "the client may provide a string image of a composite type". How does that imply multiline values. Ah; the client could embed a newline in the string. Guess I should forbid that. But I'm leaning towards eliminating API#15 anyway; given multi-level sections, I realized there's no need for it. I had it in my Windows ini package, because there is only one level of sections. > FF#4 should be written as "leading and trailing whitespace on keys > and values is semantically meaningless". Yes, much better. Thanks. > Question: Are keys case-sensitive? Good point. I think I'll go with the Ada identifier model and say "no". > Question: What about where most of the configuration is stored in a > system-wide file, with individual users capable of overriding > particular entries? Kind of like /etc/bashrc and ~/.bashrc on Linux? 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. > Question: Does the file automatically flush changes as it goes out > of scope? (API#4) Yes, I need to add that. Guess that makes it Controlled; I think it would be anyway, to avoid memory leaks. > 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. I'm planning on renaming the file to a backup name before writing it, for glitch protection. > Question: Would it make sense to allow compound values to be written > by converting a stream of them to base64 or something? I think composite values are best handled by multiple levels. Ie, if you have a record: type Foo is record a : integer; b : integer; end record; you write this as (assuming Java property style) foo.a = 1 foo.b = 2 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? Thanks for your comments! -- -- Stephe