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-28 16:21:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Config_Files proposal Date: Fri, 28 Jun 2002 18:21:30 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3D0FAC67.A4861809@san.rr.com> <3D10B6B1.AFE9D4E8@san.rr.com> <3D10E046.E604231D@san.rr.com> <3D1204B5.4620F160@san.rr.com> <3D1215A8.719D39C5@nbi.dk> <3D123852.1040508@san.rr.com> <3D1289D2.9090107@telepath.com> <3D134669.5070000@san.rr.com> X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:26778 Date: 2002-06-28T18:21:30-05:00 List-Id: To stick my head into a debate that I probably should stay out of: Stephan said: >But I still think the right answer in this case is one of: > >"use a better (multi-document) text editor". > >"use the registry for resources shared by multiple processes". > >"use separate config files for separate instances of applications" I think these are silly. I've always been dubious of this package, and if this is the result, then there is no reason to bother, because it would be totally useless. Let's look at each of these "solutions" >"use a better (multi-document) text editor". This doesn't have any effect on the problem. On modern (multi-tasking) systems, it is possible to run multiple copies of a program. If that happens, you still have the problem. For instance, you can run multiple copies of Word, even though there is no NEED to do so. And, as someone pointed out, users won't read the manual about that anyway. If you believe in solid applications (and if you don't, why are you using Ada?), "user beware" is not an option. >"use separate config files for separate instances of applications" This doesn't seem to be much of a solution, either. You're requiring the user to specify the "separate" file in some way. (You could use a PID or the like for this, but then it hardly is a config file, as it would be different for every invokation). Since this is likely to be a pain, you'll have a default. And then you'll be back to the first situation, because users won't read the manual, and they'll run multiple copies >"use the registry for resources shared by multiple processes". This of course works, but now you've lost the portability. Moreover, since I don't believe that any carefully written apps could ever assume single access, the Config_Files package could never be used. So why bother to define it? Summary: Requirement 1 has to go. For this package to be useful, it has to make it easy to create bullet-proof configuration files, and more portably than relying on the registry. (If you just want to use the registry, use Claw.Registry, which is plenty portable on Windows.) Yes, this is a lot of work. But if this was easy, there wouldn't be any need for the package. (Just writing a value to a file hardly requires a fancy package.) Randy Brukardt.