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,a26758eec3c2e1ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-20 07:43:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Use of XML for config files Date: 20 Jun 2002 10:38:00 -0400 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <4519e058.0206130553.3ee195f1@posting.google.com> <3D08CAF0.846AA176@san.rr.com> <3D08E539.343A42BF@san.rr.com> <3D0A2686.785D1BAC@san.rr.com> <3D0F53CC.E3CBB193@san.rr.com> <3D0FAA84.ED827CF5@san.rr.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1024584340 12195 128.183.220.71 (20 Jun 2002 14:45:40 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 20 Jun 2002 14:45:40 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:26488 Date: 2002-06-20T14:45:40+00:00 List-Id: Georg Bauhaus writes: > Stephen Leake wrote: > : Can you give more detail about what is missing? > : not clear what operations are implied by "administer". > > "administer" was just a very bad choice for a word, please > forget. Ok. > There is one thing that isn't missing but--from some perspective-- > might be too much. (So I could just not use it and be done with it, > of course, so what? ) There are generics for read/write of several > kinds of types. But the API could as well shift the responsibility > for interpretive reading and writing of textual and Ada > representation of data to the application, or another package. > (That's not a new thought I guess?) For example, it might be that > different people have different habits for writing floating point > numbers, e.g. money values, percent character, etc. They can do that now by writing to a string, and calling Write_String. Or, we could add something like: generic type Private_Type is private; with function To_String (Item : in Private_Type) return String; procedure Write_Private (Config : in out Configuration_Type; Key : in String; Value : in Private_Type; Error_Handling : in Error_Handling_Type := Ignore); I had that in originally, but took it out because it seemed to encourage people to use a non-standard format in the config file. But since people can get around that by just calling Write_String, maybe it's worth putting back in. Although I gather you are saying you'd be happy if I _only_ had Write_String, without any generics. > :> where the text of the explanation is written by non-programmers. I > :> can now, but my conf keys will look like x.y.de_CH, x.y.fr_FR etc. > : > : Why is that bad? Your code would be: > : explanation (property (x, "y." & Current_Language)); > : Not much different, and makes the standard Config_Files library much > : simpler. > > It's not at all bad in an application program. > (The only time I was worried about x.y.de_CH used as a key _in > the application_ was when de_CH is not unique as it is here, > but needs to be named. But this can be done by introducing > another section, x.y.lang.de_CH.) Ok. So I think you agree the current spec is ok here, and we don't need to add anything special for languages (or "localization" in general). > : Um, what do you mean by "internal"? In both of my proposed specs, > : the user must specify "x.y.de_CH". The keys are visible. > > I mean that I could possibly map "x.y.de_CH", or with the above, > "x.y.lang.de_CH" to either it's identity in a properties > file, or to ... in an XML file. Well, yes, we could define a special support for languages in XML. I don't see how it's worth it, in the Config_File context. > I'm fiddling with this and XML/Ada using the already present DOM > representation and the Config_Files interfaces. Would it make sense > to bring Grace.Config_Files_* to another hierarchical level so the > interface (e.g. as specified in Config_Files_Java) would be > implemented in different ways in child packages? I'd like to have one standard file format. You can always add a child package to implement a non-standard format. I wouldn't mind moving enough of the body into the private part of the spec to make that easier. > : The Config_Files requirements assume that everyone is "familiar" > : with simple text editors. If your users are not, then you should > : not be using Config_Files, or you should provide a different tool > : for the users to edit them with. > > Yes, exactly that is one of the strong arguments I see for > XML support. (Perhaps) optimistically, all I have to do is to send > them a suitable DTD, and a validating XML editor. Well, if you have a "validating XML editor" sitting around, that would make things easy. I didn't think such things existed. In the absence of that, I don't think it's very hard to build a special editor for config files using the Java property format. Come to think of it, somebody in the Java community has probably done just that. > I won't have to write an application that sets everything up one > their computer so they can write relatively sane configuration > files. (not sure whether this is applicable for the average Ada > program users, so maybe not an issue.) The idea is that the installer for the app using the config file writes a "sane" config file. Then the user can edit it if they need to (like if their Windows disks get renamed). You do have to write the installer for your app. > :> Well, OTOH, file formats do have consequences for what you can > :> reasonably want to be present in an API don't they? > : > : You have said exactly the opposite, just 17 lines above. > > Uhm, I said "it should look like", there is a difference :-) Well, the goal is that the API is independent of the file format. If we choose ini files, we can't have mult-level keys; that is one impact on the API. Other than that, I have not seen any impact of the file format on the API, given the other requirements on the API. -- -- Stephe