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,80b3e504140e89fd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-19 09:18:34 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn1feed!wn3feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail Message-ID: <3D10AF1F.3000805@attbi.com> From: "Robert I. Eachus" Organization: Eachus Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal References: <4519e058.0206190708.2ef205e4@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.61.239.24 X-Complaints-To: abuse@attbi.com X-Trace: rwcrnsc52.ops.asp.att.net 1024503513 24.61.239.24 (Wed, 19 Jun 2002 16:18:33 GMT) NNTP-Posting-Date: Wed, 19 Jun 2002 16:18:33 GMT Date: Wed, 19 Jun 2002 16:18:33 GMT Xref: archiver1.google.com comp.lang.ada:26393 Date: 2002-06-19T16:18:33+00:00 List-Id: Ted Dennison wrote: > So really a better question right now would be to ask if anyone has > any big objections to any of the approaches presented (other than XML, > to which the objections are already well recorded). Also, does anyone > have any strong reasons why they think one is much better than the > others? Yes. But the problem is not with the various file formats, it is with the approach. At this point we should be debating a set of requirements and a strawman interface package specification. If the result favors one or the other file format, so be it. My expectation is that a good set of requirements and interface will allow more than one underlying implementation. I'd love to see a result that maps to registry, .ini files, and .cfg files with no differences in usage outside the create and/or open parameters.