* config files proposal @ 2002-06-02 16:07 Stephen Leake 2002-06-02 21:29 ` Darren New ` (4 more replies) 0 siblings, 5 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-02 16:07 UTC (permalink / raw) I've posted a summary of the requirements and options for a config file standard, at http://users.erols.com/leakstan/Stephe/Ada/config_files.html I'm going to experiment with an XML implementation before I post a draft spec; I suspect using XML for the file format will have an impact on the spec. If I find XML too complex, I'm leaning towards the Java property style. Please comment on the requirements. Please don't say "just use the registry"; let's take that discussion as settled :). The consensus is we need both the registry and a simpler config file. I'm on vacation starting Tuesday (back the following Monday), so I won't be responding to comments till then. I'll try to catch up on all of this thread when I get back, but feel free to send me email directly at stephen_leake@acm.org. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 16:07 config files proposal Stephen Leake @ 2002-06-02 21:29 ` Darren New 2002-06-02 22:00 ` Darren New 2002-06-02 22:16 ` Stephen Leake 2002-06-04 15:41 ` Antonio Duran ` (3 subsequent siblings) 4 siblings, 2 replies; 69+ messages in thread From: Darren New @ 2002-06-02 21:29 UTC (permalink / raw) Stephen Leake wrote: > http://users.erols.com/leakstan/Stephe/Ada/config_files.html I would suggest using Wide_String for keys. (API#8) You need to specify where a file is written in the path. (API#6) apparently only talks about reading files. 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. FF #3 I would disagree with. It limits having large items in the config file format. Making key/value pairs terminated by a newline is specifying the implementation. It doesn't make any sense to do such a thing in XML, for example. Perhaps starting continuation lines with a space as is done in RFC 822 headers would make more sense. In addition, API#15 conflicts with this requirement. FF#4 should be written as "leading and trailing whitespace on keys and values is semantically meaningless". Question: Are keys case-sensitive? 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? Question: Does the file automatically flush changes as it goes out of scope? (API#4) Question: Is the file closed (w.r.t. the OS) between the end of the read and the start of the write? Question: Would it make sense to allow compound values to be written by converting a stream of them to base64 or something? -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 21:29 ` Darren New @ 2002-06-02 22:00 ` Darren New 2002-06-02 22:16 ` Stephen Leake 1 sibling, 0 replies; 69+ messages in thread From: Darren New @ 2002-06-02 22:00 UTC (permalink / raw) Darren New wrote: > FF#4 should be written as "leading and trailing whitespace on keys and > values is semantically meaningless". Oh, and then you have to specify the quoting rules for values where leading and/or trailing whitespace *is* significant. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 21:29 ` Darren New 2002-06-02 22:00 ` Darren New @ 2002-06-02 22:16 ` Stephen Leake 2002-06-03 4:20 ` Darren New ` (2 more replies) 1 sibling, 3 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-02 22:16 UTC (permalink / raw) Darren New <dnew@san.rr.com> 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 22:16 ` Stephen Leake @ 2002-06-03 4:20 ` Darren New 2002-06-09 20:16 ` Stephen Leake 2002-06-03 14:56 ` Ted Dennison 2002-06-03 15:13 ` Preben Randhol 2 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-03 4:20 UTC (permalink / raw) Stephen Leake wrote: > > 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. The problem here is if you load a system-wide config file, make changes, and want to save it. You at least need a routine that says "pretend you got it from *here*" or something; i.e., to change the name&path of the file between reading and writing. > > 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. Hrm. Perhaps. > > 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. Right. Actually, I read it as "provides a way to read/write the value". I hadn't read it as "... as a String value" but I guess someone more atuned to Ada would read it that way. > 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. I think it depends on just how you build the API. > > Question: Are keys case-sensitive? > > Good point. I think I'll go with the Ada identifier model and say > "no". If "no" and you're allowing Unicode, then you have to worry about the bizarre transformations that some languages have. > 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. That's how I've always done it. That also solves the problem of "where do I store changes if there was no file found when I read?" > I'm planning on renaming the file to a backup name before writing it, > for glitch protection. Make that optional. Or write to a new file, and rename over the old one. Some OSes may do this for you automatically. Other OSes supply specific routines to do this properly (maintaining file attributes and ACLs, etc.) > 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? That was actually my thought, yes. Funky how we both had the same example in mind. > Thanks for your comments! Thanks for paying attention! :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 4:20 ` Darren New @ 2002-06-09 20:16 ` Stephen Leake 2002-06-10 1:33 ` Darren New 0 siblings, 1 reply; 69+ messages in thread From: Stephen Leake @ 2002-06-09 20:16 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > > 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. > > The problem here is if you load a system-wide config file, make changes, and > want to save it. You at least need a routine that says "pretend you got it > from *here*" or something; i.e., to change the name&path of the file between > reading and writing. Good point. I guess I can check the write privs on the found file. Or provide two search paths; one read-only and one writeable. > > > Question: Are keys case-sensitive? > > > > Good point. I think I'll go with the Ada identifier model and say > > "no". > > If "no" and you're allowing Unicode, then you have to worry about the > bizarre transformations that some languages have. yes. And Glib.XML is case sensitive. Although Glib.XML also uses String for Tags, not Wide_String. So I have to check the XML definition; does it allow Wide_String for tags? Hmm. http://www.w3.org/TR/2000/REC-xml-20001006#NT-Letter seems to imply 16 bit characters, but I'm not clear on whether it's UniCode or something else. There's also the issue of what Wide_Text_IO actually writes. > > 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? > > That was actually my thought, yes. Funky how we both had the same example in > mind. Yes. However, a better solution for bitmaps is to keep the bitmap in a file that a bitmap editor will recognize, and put the path to it (possibly relative) in the config file. But we don't need to _forbid_ binary data in the config file, if it's not hard to do. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-09 20:16 ` Stephen Leake @ 2002-06-10 1:33 ` Darren New 2002-06-10 12:35 ` Stephen Leake 2002-06-10 14:23 ` Georg Bauhaus 0 siblings, 2 replies; 69+ messages in thread From: Darren New @ 2002-06-10 1:33 UTC (permalink / raw) Stephen Leake wrote: > Good point. I guess I can check the write privs on the found file. Naw. > Or provide two search paths; one read-only and one writeable. Or just require the full path to the config to be saved, and perhaps default it to where it was loaded from. I think if you try to "guess" which config file to clobber, you're going to guess wrong too often. > > If "no" and you're allowing Unicode, then you have to worry about the > > bizarre transformations that some languages have. > > yes. And Glib.XML is case sensitive. Although Glib.XML also uses > String for Tags, not Wide_String. So I have to check the XML > definition; does it allow Wide_String for tags? Hmm. XML is case sensitive and uses unicode. > http://www.w3.org/TR/2000/REC-xml-20001006#NT-Letter seems to imply 16 > bit characters, but I'm not clear on whether it's UniCode or something > else. UTF-8 or UTF-16, as far as I understand. > There's also the issue of what Wide_Text_IO actually writes. That too. > Yes. However, a better solution for bitmaps is to keep the bitmap in a > file that a bitmap editor will recognize, and put the path to it > (possibly relative) in the config file. Possibly. Depends on what you're trying to accomplish. > But we don't need to _forbid_ binary data in the config file, if it's > not hard to do. Correct. But if you want it editable, you probably need to keep it text. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 1:33 ` Darren New @ 2002-06-10 12:35 ` Stephen Leake 2002-06-10 15:42 ` Darren New 2002-06-10 14:23 ` Georg Bauhaus 1 sibling, 1 reply; 69+ messages in thread From: Stephen Leake @ 2002-06-10 12:35 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > Good point. I guess I can check the write privs on the found file. > > Naw. Hmm. What if I find a "system" config file, that I _don't_ have write priviledge for? > > Or provide two search paths; one read-only and one writeable. > > Or just require the full path to the config to be saved, and perhaps default > it to where it was loaded from. I think if you try to "guess" which config > file to clobber, you're going to guess wrong too often. With clear rules about it, there's no "guessing". Here's my proposed rule: --- There are two search paths; one for files that are read only, one for files that are writeable. If the first config file is found on a read only path, the "flush" operation creates a new file in the first directory of the writeable path. --- That gives total control to the client of the Config_Files package. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 12:35 ` Stephen Leake @ 2002-06-10 15:42 ` Darren New 0 siblings, 0 replies; 69+ messages in thread From: Darren New @ 2002-06-10 15:42 UTC (permalink / raw) Stephen Leake wrote: > > Darren New <dnew@san.rr.com> writes: > > > Stephen Leake wrote: > > > Good point. I guess I can check the write privs on the found file. > > > > Naw. > > Hmm. What if I find a "system" config file, that I _don't_ have write > priviledge for? Sorry. I forgot to finish that sentence. I meant "Naw, that's not good enough." Or would you want root changing the system configuration every time she ran your program? > > > Or provide two search paths; one read-only and one writeable. > > > > Or just require the full path to the config to be saved, and perhaps default > > it to where it was loaded from. I think if you try to "guess" which config > > file to clobber, you're going to guess wrong too often. > > With clear rules about it, there's no "guessing". Here's my proposed > rule: > > --- > There are two search paths; one for files that are read only, one for > files that are writeable. > > If the first config file is found on a read only path, the "flush" > operation creates a new file in the first directory of the writeable > path. > --- > > That gives total control to the client of the Config_Files package. That would work, yes. That's a good compirimse. Especially if one can change these paths at run-time, on a per-config-file basis. In that case, one could simply change the writable path to a single directory to force a config file to be written. I'd also suggest that it be legal to have a zero-length writable path, leading to an exception if an attempt is made to write the config file. (Or perhaps to have changes discarded?) Altho I must admit I see no reason for a writable *path* as such. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 1:33 ` Darren New 2002-06-10 12:35 ` Stephen Leake @ 2002-06-10 14:23 ` Georg Bauhaus 1 sibling, 0 replies; 69+ messages in thread From: Georg Bauhaus @ 2002-06-10 14:23 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: : : UTF-8 or UTF-16, as far as I understand. <?xml version='1.0' encoding='...'?> declares "external representation". External entities in UTF-8/16 must be read, others may. UTF-8 has the advantage of being stateless and compatible across wires. We often have <?xml version='1.0' encoding='ISO-8859-1'?>, useless for anything outside "west-latin" tradition, but good and correct otherwise. -- georg ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 22:16 ` Stephen Leake 2002-06-03 4:20 ` Darren New @ 2002-06-03 14:56 ` Ted Dennison 2002-06-03 16:08 ` Darren New 2002-06-09 20:29 ` Stephen Leake 2002-06-03 15:13 ` Preben Randhol 2 siblings, 2 replies; 69+ messages in thread From: Ted Dennison @ 2002-06-03 14:56 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkznydwcm7.fsf@acm.org>... > Darren New <dnew@san.rr.com> 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. 2) There will be only one config file per system. 3) The facility will be dependent on the very system-dependant feature of directory search paths. I don't like the first two ideas at all, since they needlessly restrict the funtionality. 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. Clients of the facility should be able to read and write configurations to and from the directories and file names of their choice. 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. 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 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. > > 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. :-) > > 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". Presumably this is just a first cut to get the "easy ones" ironed out, before we start to agree on a file format. Right? If so, a lot of this discussion will be rendered moot when the file format is decided upon. > > Question: Are keys case-sensitive? > > Good point. I think I'll go with the Ada identifier model and say > "no". I agree wholeheartedly, for the same reason. > 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. 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. > > 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. > I'm planning on renaming the file to a backup name before writing it, > for glitch protection. Ditto > 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. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 14:56 ` Ted Dennison @ 2002-06-03 16:08 ` Darren New 2002-06-03 16:24 ` Jean-Marc Bourguet ` (2 more replies) 2002-06-09 20:29 ` Stephen Leake 1 sibling, 3 replies; 69+ messages in thread From: Darren New @ 2002-06-03 16:08 UTC (permalink / raw) Ted Dennison wrote: > > > Question: Are keys case-sensitive? > > > > Good point. I think I'll go with the Ada identifier model and say > > "no". > > I agree wholeheartedly, for the same reason. I think they should be case sensitive unless there's a standard way of converting uppercase unicode to lowercase unicode in Ada's libraries. Remember that (for example) you'll probably want to store this stuff in a Map, implying a hashtable perhaps, meaning you'll need to convert between whatever is supplied and either upper or lower case, and do so in the same way a native speaker of the language would do so. Remember too that (for example) the lower-case version of some German words don't even have the same length as the upper-case version. And I'm not even sure there's general agreement on whether uppercase letters in French have the accent included or not. And I don't even *know* if there is the equivalent with different Chinese, Japanese, or Cyrilic characters, for example. While it's admirable to ignore the case of the letters, I think trying to implement a general "to_lower" that'll handle Unicode properly is going to be more of a nightmare than writing the entire rest of the config file parser. Unless you restrict the keys to US-ASCII, that is. Just something to consider. > 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. Yes, I think that's a good way to go also. At least, that's how I do it. :-) I think there should also be some sort of tag at the front of each file saying it's an Ada config file, even if only -- Ada Grace.Config file V1.0 -- Do not hand-edit. so one could check you've found a proper file and know what version it is. > > 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. I think it's an important detail for systems where having a file open changes the semantics for other users. If, for example, you leave it open after you write it, it's possible I won't be able to read it. If you leave it open after reading it, I may be dedicating resources on the file server to keeping track of it (assuming it's centrally served, for example). Closing it each time would make it easier to reason about multiple users using the same config file, and the overhead of reopening it should be minimal, given it's a config file. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 16:08 ` Darren New @ 2002-06-03 16:24 ` Jean-Marc Bourguet 2002-06-03 16:50 ` Darren New 2002-06-04 19:55 ` Ted Dennison 2002-06-09 20:39 ` Stephen Leake 2 siblings, 1 reply; 69+ messages in thread From: Jean-Marc Bourguet @ 2002-06-03 16:24 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > While it's admirable to ignore the case of the letters, I think trying to > implement a general "to_lower" that'll handle Unicode properly is going to > be more of a nightmare than writing the entire rest of the config file > parser. Unless you restrict the keys to US-ASCII, that is. Well unicode define canonical forms (4 of them: x2 for the case issues, x2 for determining if things like "superscript 2" and 2 are equivalent). And you are right, the case independant canonical forms are dependent on the locale. But even for case dependant comparisons, using canonical form is needed as some glyphs have multiple representations. Yours, -- Jean-Marc ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 16:24 ` Jean-Marc Bourguet @ 2002-06-03 16:50 ` Darren New 2002-06-04 11:07 ` Preben Randhol 0 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-03 16:50 UTC (permalink / raw) Jean-Marc Bourguet wrote: > But even for case dependant comparisons, using canonical form is > needed as some glyphs have multiple representations. OK. Does Ada define Unicode libraries that let you work with this? Does GNAT? :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 16:50 ` Darren New @ 2002-06-04 11:07 ` Preben Randhol 0 siblings, 0 replies; 69+ messages in thread From: Preben Randhol @ 2002-06-04 11:07 UTC (permalink / raw) On Mon, 03 Jun 2002 16:50:41 GMT, Darren New wrote: > Jean-Marc Bourguet wrote: >> But even for case dependant comparisons, using canonical form is >> needed as some glyphs have multiple representations. > > OK. Does Ada define Unicode libraries that let you work with this? Does > GNAT? :-) http://sourceforge.net/projects/ngeadal/ Preben ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 16:08 ` Darren New 2002-06-03 16:24 ` Jean-Marc Bourguet @ 2002-06-04 19:55 ` Ted Dennison 2002-06-09 20:43 ` Stephen Leake 2002-06-09 20:39 ` Stephen Leake 2 siblings, 1 reply; 69+ messages in thread From: Ted Dennison @ 2002-06-04 19:55 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3CFB94A7.A455B8DD@san.rr.com>... > I think they should be case sensitive unless there's a standard way of > converting uppercase unicode to lowercase unicode in Ada's libraries. We need to match up well with what's in the Ada standard I think. The Ada standard has an Ada.Strings.Maps.Constants.Lower_Case_Map and an Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map. There is no reason why we can't define things to say that keys will be fed through the appropriate Lower_Case_Map before being matched. If the language itself has some kind of problem with Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map, I say that is the language's problem, and outside the scope of a configuration item facility to try to worry about fixing. As long as we define what we are doing carfully this way, it is still explicit. If we stick to using the standard library, things should at least behave for people the way they have come to expect them to behave when using Ada. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-04 19:55 ` Ted Dennison @ 2002-06-09 20:43 ` Stephen Leake 0 siblings, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 20:43 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Darren New <dnew@san.rr.com> wrote in message > news:<3CFB94A7.A455B8DD@san.rr.com>... > > I think they should be case sensitive unless there's a standard way of > > converting uppercase unicode to lowercase unicode in Ada's libraries. > > We need to match up well with what's in the Ada standard I think. > > The Ada standard has an Ada.Strings.Maps.Constants.Lower_Case_Map and > an Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map. There is no > reason why we can't define things to say that keys will be fed through > the appropriate Lower_Case_Map before being matched. Good point. > If the language itself has some kind of problem with > Ada.Strings.Wide_Maps.Wide_Constants.Lower_Case_Map, I say that is > the language's problem, and outside the scope of a configuration > item facility to try to worry about fixing. As long as we define > what we are doing carfully this way, it is still explicit. If we > stick to using the standard library, things should at least behave > for people the way they have come to expect them to behave when > using Ada. According to my interpretation of recent posts by Robert Dewar (is that qualified enough :), there is very little use of Wide_String. So it's not clear whether Lower_Case_Map is "what people expect". But I agree it would be a good place to start. Perhaps case sensitivity should be an option in the config file API. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 16:08 ` Darren New 2002-06-03 16:24 ` Jean-Marc Bourguet 2002-06-04 19:55 ` Ted Dennison @ 2002-06-09 20:39 ` Stephen Leake 2002-06-10 1:33 ` Darren New 2 siblings, 1 reply; 69+ messages in thread From: Stephen Leake @ 2002-06-09 20:39 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > I think there should also be some sort of tag at the front of each file > saying it's an Ada config file, even if only > > -- Ada Grace.Config file V1.0 -- Do not hand-edit. Part of the point is to _allow_ hand editing :). > so one could check you've found a proper file and know what version > it is. Yes, I'm leaning towards a standard implemntation of config file versions. If only to hint to application builders that they should consider versioning issues! It's easy to do in the root tag of an XML document. > > > 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. > > I think it's an important detail for systems where having a file open > changes the semantics for other users. Not for config files. These are _explicitly_ not accessible by parallel processes. Hmm. Guess I have to allow read-only parallel access if I'm allowing system-wide config files. Sigh. Why do things have to be so complicated? So yes, the file is closed at the end of an open operation. > If, for example, you leave it open after you write it, it's possible > I won't be able to read it. Arg. Who gets to write a system config file? This is why I wanted to exclude parallel access. > If you leave it open after reading it, I may be dedicating resources > on the file server to keeping track of it (assuming it's centrally > served, for example). Closing it each time would make it easier to > reason about multiple users using the same config file, and the > overhead of reopening it should be minimal, given it's a config > file. Yeah, I think closing it after each open and flush should be required. This will still depend on OS file system locking for preventing read while someone has a file open for write. That is _not_ required by the config file API, so we can use it on a primitive OS like VxWorks (hmm, maybe VxWorks has file locking?) or DOS. But it is an added feature of using a real OS. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-09 20:39 ` Stephen Leake @ 2002-06-10 1:33 ` Darren New 2002-06-10 10:17 ` Preben Randhol 0 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-10 1:33 UTC (permalink / raw) Stephen Leake wrote: > > Darren New <dnew@san.rr.com> writes: > > > I think there should also be some sort of tag at the front of each file > > saying it's an Ada config file, even if only > > > > -- Ada Grace.Config file V1.0 -- Do not hand-edit. > > Part of the point is to _allow_ hand editing :). Right. But it should still be marked "don't do that". Or maybe "Read manual before hand-editing". ;-) > > I think it's an important detail for systems where having a file open > > changes the semantics for other users. > > Not for config files. These are _explicitly_ not accessible by > parallel processes. Um... So, if my config file is open, and thus my backup program doesn't back it up, is that good or bad? If a program is running that only reads config files, should I be allowed to copy the config file it uses to a different directory while it's running? I'm not just talking about multiple users of the config file API trying to write at the same time. > Hmm. Guess I have to allow read-only parallel access if I'm allowing > system-wide config files. Sigh. Why do things have to be so > complicated? > > So yes, the file is closed at the end of an open operation. Yeah. Just so much eaiser. :-) > > If, for example, you leave it open after you write it, it's possible > > I won't be able to read it. > > Arg. Who gets to write a system config file? This is why I wanted to > exclude parallel access. Well, *somebody* has to write it, yes? I'm just saying that not all the world is UNIX, and not every OS defaults to letting you edit files that are already open. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 1:33 ` Darren New @ 2002-06-10 10:17 ` Preben Randhol 0 siblings, 0 replies; 69+ messages in thread From: Preben Randhol @ 2002-06-10 10:17 UTC (permalink / raw) On Mon, 10 Jun 2002 01:33:28 GMT, Darren New wrote: > Right. But it should still be marked "don't do that". Or maybe "Read manual > before hand-editing". ;-) No it should not read "Don't handedit" if you will allow the user to do this. It should be the latter you said. The reason is that for the files that you don't want a user to hand edit you should reserve the "Don't edit". Then the user understands that it is serious. Preben ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-03 14:56 ` Ted Dennison 2002-06-03 16:08 ` Darren New @ 2002-06-09 20:29 ` Stephen Leake 2002-06-10 1:33 ` Darren New 2002-06-10 18:58 ` Ted Dennison 1 sibling, 2 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 20:29 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Stephen Leake <stephen_leake@acm.org> wrote in message > news:<wkznydwcm7.fsf@acm.org>... > > Darren New <dnew@san.rr.com> 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-09 20:29 ` Stephen Leake @ 2002-06-10 1:33 ` Darren New 2002-06-10 18:58 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Darren New @ 2002-06-10 1:33 UTC (permalink / raw) Stephen Leake wrote: > 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 :). So does Windows. (Under NTFS at least.) It's just that nobody uses them. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-09 20:29 ` Stephen Leake 2002-06-10 1:33 ` Darren New @ 2002-06-10 18:58 ` Ted Dennison 2002-06-11 18:11 ` Stephen Leake 1 sibling, 1 reply; 69+ messages in thread From: Ted Dennison @ 2002-06-10 18:58 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkr8jgrya2.fsf@acm.org>... > I'd like to have a general "binary data - not human editable" data > type. Maybe with an Ada Streams interface? An intersting idea. But if you have a separate data type for binary data, don't you open the door for other data types, eg: Float, Integer, Duration, Date/Time, etc? -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 18:58 ` Ted Dennison @ 2002-06-11 18:11 ` Stephen Leake 0 siblings, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-11 18:11 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > Stephen Leake <stephen_leake@acm.org> wrote in message > news:<wkr8jgrya2.fsf@acm.org>... > > I'd like to have a general "binary data - not human editable" data > > type. Maybe with an Ada Streams interface? > > An intersting idea. But if you have a separate data type for binary > data, don't you open the door for other data types, eg: Float, > Integer, Duration, Date/Time, etc? Well, we already have "approved" interfaces for scalar types. Yes, the user could abuse the binary interface to store a Date, rather than adding an appropriate interface for Calendar.Time. That's not bad as a quick work-around. My motto for this is "I need the power to shoot myself in the foot, and the discipline not too". -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 22:16 ` Stephen Leake 2002-06-03 4:20 ` Darren New 2002-06-03 14:56 ` Ted Dennison @ 2002-06-03 15:13 ` Preben Randhol 2 siblings, 0 replies; 69+ messages in thread From: Preben Randhol @ 2002-06-03 15:13 UTC (permalink / raw) On Sun, 02 Jun 2002 22:16:00 GMT, Stephen Leake wrote: > Darren New <dnew@san.rr.com> writes: > >> Stephen Leake wrote: >> 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? xpm is ASCII based. If you start including base64 in the config files there will be a lot of data corruption. If one need to use sth like that then the config file should be binary so a user cannot edit it. The user of the package can easily make more than one config file. Example: User editable settings goes in settings.config Program settings (like coulours, variables) goes in program.data Then program.data can be binary or whatever, while settings.config is ASCII. I don't think the package should know which OS it is running on. I mean the developer should give it the propper Path to look in I think. Preben ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 16:07 config files proposal Stephen Leake 2002-06-02 21:29 ` Darren New @ 2002-06-04 15:41 ` Antonio Duran 2002-06-04 15:51 ` Darren New ` (2 more replies) 2002-06-04 17:06 ` Darren New ` (2 subsequent siblings) 4 siblings, 3 replies; 69+ messages in thread From: Antonio Duran @ 2002-06-04 15:41 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote in message news:<wkelfpy887.fsf@acm.org>... > I've posted a summary of the requirements and options for a config > file standard, at > http://users.erols.com/leakstan/Stephe/Ada/config_files.html > > I'm going to experiment with an XML implementation before I post a > draft spec; I suspect using XML for the file format will have an > impact on the spec. If I find XML too complex, I'm leaning towards the > Java property style. > > Please comment on the requirements. > > Please don't say "just use the registry"; let's take that discussion > as settled :). The consensus is we need both the registry and a > simpler config file. > > I'm on vacation starting Tuesday (back the following Monday), so I > won't be responding to comments till then. I'll try to catch up on all > of this thread when I get back, but feel free to send me email > directly at stephen_leake@acm.org. In relation to config files there are some points that I would like to comment. I don't read the entire thread so please, forgive me if some or all of them were previously discussed. 1. In my experience, most of the time, config files are writen, edited or modified by humans and read and interpreted by programs. With this in mind, in my modest opinion, the importance of having an API for writing to config files is secondary. What is important is having the means that allow a human user to understand what is in the config file. Configuration tasks are simpler if the config file is commented and handling comments is difficult if you use an API call to write to the file. When config file gets complicated enough one must write an application to handle it (eg. Comanche to mantain Apache config files). 2. Seems that there is a consensus in that a config file must store key/value(s) pairs. I don't understand the requirement to use Wide_String for keys. I'm from Spain and I usually write in Spanish but when programming in Ada I must adhere to the Ada syntax, I can't write Ada identifiers that are syntactically correct spanish words and the Ada reserved words are english words. Supporting Wide_String could be a cool feature for, for example, mantaining localized messages in different languages, however: is this the purpose of config files?. I think the purpose of config files is to provide parameters to a program or application and not to be used as a repository for localized versions of program messages. Of course, they could be used in that way. I suggest that keys in config file meet the Ada syntax for identifier and be case-insensitive. 3. I think that is important to handle more than one config file in a single program. From my point of view, one of the most important drawbacks of layouts such as the Windows Registry is that everything is on a single place so applications that can access to a single part can also write other parts. In complicated apps it could be desirable to mantain a set of different config files one for each part of the application. The ability for handling multiple config files in a single program should be a requirement for a config file handling package. 4. I don't understand very well the implications of "... specified by generic parameter at compile time ..." (API req. 5). Does this mean that the name or the path of the file must be hard coded?. If so I think we've missed totally the point (should I recompile each time I change the name or location of the config file?). 5. Regarding to the file syntax, long time ago I worked on a system that runs on CAIS (Common APSE Interface Set). CAIS contains a List Management package that provides great power for handling parameter lists and those lists have a human readable text representation. That text representation is, from my point of view, more Ada like and could be used as a base syntax for config files. The example provided in the Stephen requirements page would be (comments were not allowed in CAIS Lists) -- Config file TBD. ( -- ServerLayout Section. ServerLayout => ( Identifier => "Default Layout", Screen => ("Default Screen", 0, 0), InputDevice => ( "Generic Keyboard", "Configured Mouse", "Generic Mouse" ), Display => ( Depth => 1, Modes => ( (Width => 16#400#, Height => 768), (Width => 800, Height => 600) -- New mode added. ) ) ) -- End of ServerLayout section. ) -- End of config file TBD There are, however, some drawbacks in this representation: - A escaping schema is needed for unprintable characters in strings (?). - Nested '(' and ')' would add a high degree of complexity for the human user/reader. Antonio Duran ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-04 15:41 ` Antonio Duran @ 2002-06-04 15:51 ` Darren New 2002-06-05 10:17 ` Antonio Duran 2002-06-05 14:31 ` Ted Dennison 2002-06-05 19:12 ` Syntactically correct spanish identifiers (Was: config files proposal) Jacob Sparre Andersen 2002-06-09 20:54 ` config files proposal Stephen Leake 2 siblings, 2 replies; 69+ messages in thread From: Darren New @ 2002-06-04 15:51 UTC (permalink / raw) Antonio Duran wrote: > 1. In my experience, most of the time, config files are writen, edited > or modified by humans and read and interpreted by programs. I think that's true on UNIX (esp. server programs) much more so than on Windows. I can't remember the last time I edited configuration manually on Windows. > 2. ... A good argument. > 3. I think that is important to handle more than one config file in a > single program. Unquestionably. > From my point of view, one of the most important > drawbacks of layouts such as the Windows Registry is that everything > is on a single place so applications that can access to a single part > can also write other parts. Errrr... if you ignore the ACLs on registry entries, sure. That's like saying the problem with UNIX is it's all files, so if you can write to one you can write to them all. > In complicated apps it could be desirable > to mantain a set of different config files one for each part of the > application. The ability for handling multiple config files in a > single program should be a requirement for a config file handling > package. I think it's also important to have system-wide, program-wide, and user-wide config files. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-04 15:51 ` Darren New @ 2002-06-05 10:17 ` Antonio Duran 2002-06-05 14:31 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Antonio Duran @ 2002-06-05 10:17 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3CFCE218.585D56E2@san.rr.com>... > I think that's true on UNIX (esp. server programs) much more so than on > Windows. I can't remember the last time I edited configuration manually on > Windows. > Maybe I'm not lucky enough since I recently had to configure Apache, PHP, and MySQL on my machine and had to deal with text based config files but these applications are not Windows native (that is, only for Windows) ;-). Of course, using a text editor rather than a specific tool is more error prone and one must take care of specific syntax issues (eg. editing the hosts file and that tricky tab at the beginning of entries). > Errrr... if you ignore the ACLs on registry entries, sure. That's like > saying the problem with UNIX is it's all files, so if you can write to one > you can write to them all. Right, I've ignored ACLs on registry entries (maybe because my experience is on Windows 98). While I recognize the advantanges of having configuration data in a single place (common tools for handling data) I'm also concerned with, as we say in Spain, "putting all the eggs in the same basket". There is a risk of loosing all your configuration data. This is not only a Windows problem, as I recall, on AIX there is also a repository for config data (I think its name is RODM or something like that). Moreover, the data storage format of those repositories is propietary, tailored to a specific system, and, in general, even if you backed up your config data is complicated to restore them back after a system crash. While is true that on Unix, if you loose the contents of your /etc directory you're in big trouble is also true that it contains ordinary files and restoring them (provided you backed up them) is easier. > I think it's also important to have system-wide, program-wide, and user-wide > config files. Agree. Thank you for your answer and best regards, Antonio Dur�n ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-04 15:51 ` Darren New 2002-06-05 10:17 ` Antonio Duran @ 2002-06-05 14:31 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Ted Dennison @ 2002-06-05 14:31 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3CFCE218.585D56E2@san.rr.com>... > Antonio Duran wrote: > > 1. In my experience, most of the time, config files are writen, edited > > or modified by humans and read and interpreted by programs. > > I think that's true on UNIX (esp. server programs) much more so than on > Windows. I can't remember the last time I edited configuration manually on > Windows. That's because of the way Windows is designed. With everything thrown in one big database (the registry), the penalty for a user hosing the configuration file is just too great to risk it. Every program *has* to inlcude support for updating registry settings safely, lest they risk their users hosing their entire system. It doesn't sound like we are planning a "monolithic database" approach, so this won't be an issue for us. That said, I actually go into the registry manually myself lots, and I know there are plenty of Microsoft support pages that specify procedures involving manually updating the registry. The procedure for setting up autologon in NT is an example. > > 3. I think that is important to handle more than one config file in a > > single program. > > Unquestionably. Then clearly we are *not* in the "one monolithic database" situation. > I think it's also important to have system-wide, program-wide, and user-wide > config files. How "wide" they are should be up to the developer to set up and support. However, the facility should allow for such setups. For instance, if chaining is supported, then a Unix developer could put the first file in ~, the second in the installation directory, and the third in /usr/local somewhere. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* Syntactically correct spanish identifiers (Was: config files proposal) 2002-06-04 15:41 ` Antonio Duran 2002-06-04 15:51 ` Darren New @ 2002-06-05 19:12 ` Jacob Sparre Andersen 2002-06-06 1:49 ` Robert Dewar 2002-06-09 20:54 ` config files proposal Stephen Leake 2 siblings, 1 reply; 69+ messages in thread From: Jacob Sparre Andersen @ 2002-06-05 19:12 UTC (permalink / raw) Antonio Duran wrote: > I'm from Spain and I usually write in Spanish > but when programming in Ada I must adhere to the Ada syntax, I can't > write Ada identifiers that are syntactically correct spanish words Are you sure? I am almost certain that ISO-8859-1 is intended for writing Spanish. It is also the character encoding used for Ada source code. But there are still good reasons to use English identifiers in your Ada programs. Jacob -- "Vi f�r ikke andet sk�g end det vi selv kan finde p�." ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Syntactically correct spanish identifiers (Was: config files proposal) 2002-06-05 19:12 ` Syntactically correct spanish identifiers (Was: config files proposal) Jacob Sparre Andersen @ 2002-06-06 1:49 ` Robert Dewar 2002-06-07 8:07 ` Antonio Duran 0 siblings, 1 reply; 69+ messages in thread From: Robert Dewar @ 2002-06-06 1:49 UTC (permalink / raw) Jacob Sparre Andersen <sparre@nbi.dk> wrote in message news:<3CFE62B5.BEC2ED6B@nbi.dk>... > Antonio Duran wrote: > > > I'm from Spain and I usually write in Spanish > > but when programming in Ada I must adhere to the Ada syntax, I can't > > write Ada identifiers that are syntactically correct spanish words > > Are you sure? I am almost certain that ISO-8859-1 is > intended for writing Spanish. It is also the character > encoding used for Ada source code. yes, of course, the default interpretation of type Character is Latin-1 which includes all necessary characters for writing Spanish, and this is also the default interpretation of program sources, so identifiers can be written in Spanish with proper upper/lower case equivalences. What would be interesting is to know is what you (Antonio) read that made you think otherwise??? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Syntactically correct spanish identifiers (Was: config files proposal) 2002-06-06 1:49 ` Robert Dewar @ 2002-06-07 8:07 ` Antonio Duran 2002-06-07 15:37 ` Robert Dewar 0 siblings, 1 reply; 69+ messages in thread From: Antonio Duran @ 2002-06-07 8:07 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0206051749.558ed3fb@posting.google.com>... > Jacob Sparre Andersen <sparre@nbi.dk> wrote in message news:<3CFE62B5.BEC2ED6B@nbi.dk>... > > Antonio Duran wrote: > > > > > I'm from Spain and I usually write in Spanish > > > but when programming in Ada I must adhere to the Ada syntax, I can't > > > write Ada identifiers that are syntactically correct spanish words > > > > Are you sure? I am almost certain that ISO-8859-1 is > > intended for writing Spanish. It is also the character > > encoding used for Ada source code. > > yes, of course, the default interpretation of type Character is Latin-1 which > includes all necessary characters for writing Spanish, and this is also the > default interpretation of program sources, so identifiers can be written in > Spanish with proper upper/lower case equivalences. > > What would be interesting is to know is what you (Antonio) read that made > you think otherwise??? You are right, it is syntactically correct in Ada 95 to write identifiers using acute vowels. I don't pretend to excuse myself but I made the transition from Ada 83 to 95 and I skipped the first two chapters of the LRM. By the way, what I read, for general syntax subjects is the ANSI/MIL STD 1815 from "Ada Compilers and Bibliography" (Cambridge University Press). I feel sorry for open an issue that only shows my ignorance. Next time I will think before write. Thank you, Antonio Duran ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Syntactically correct spanish identifiers (Was: config files proposal) 2002-06-07 8:07 ` Antonio Duran @ 2002-06-07 15:37 ` Robert Dewar 0 siblings, 0 replies; 69+ messages in thread From: Robert Dewar @ 2002-06-07 15:37 UTC (permalink / raw) antonio_duran@hotmail.com (Antonio Duran) wrote in message news:<e1a50f2.0206070007.68e343e@posting.google.com>... > dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0206051749.558ed3fb@posting.google.com>... > I feel sorry for open an issue that only shows my ignorance. Next time > I will think before write. Thank you, If lack of ignorance is defined as knowing everything that is in the RM, then nearly all of us, including certainly me, are ignorant, so you don't need to apologize :-) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-04 15:41 ` Antonio Duran 2002-06-04 15:51 ` Darren New 2002-06-05 19:12 ` Syntactically correct spanish identifiers (Was: config files proposal) Jacob Sparre Andersen @ 2002-06-09 20:54 ` Stephen Leake 2002-06-10 1:33 ` Darren New 2002-06-13 15:52 ` Georg Bauhaus 2 siblings, 2 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 20:54 UTC (permalink / raw) antonio_duran@hotmail.com (Antonio Duran) writes: > 1. In my experience, most of the time, config files are writen, edited > or modified by humans and read and interpreted by programs. With this > in mind, in my modest opinion, the importance of having an API for > writing to config files is secondary. What is important is having the > means that allow a human user to understand what is in the config > file. True. > Configuration tasks are simpler if the config file is commented and > handling comments is difficult if you use an API call to write to > the file. Good point; I hadn't thought of that. I think this makes XML a better idea; we can allow for a "comment" tag that is saved in the memory image, and written back out. > When config file gets complicated enough one must write an > application to handle it (eg. Comanche to mantain Apache config > files). Yes. We need to support both modes of operation. > 2. Seems that there is a consensus in that a config file must store > key/value(s) pairs. I don't understand the requirement to use > Wide_String for keys. I'm from Spain and I usually write in Spanish > but when programming in Ada I must adhere to the Ada syntax, I can't > write Ada identifiers that are syntactically correct spanish words > and the Ada reserved words are english words. Yes, but there's no reason config files have to have the same restrictions. > Supporting Wide_String could be a cool feature for, for example, > mantaining localized messages in different languages, however: is > this the purpose of config files?. You could use them that way. In this particular case, the Gnu 'get_text' facility is probably better. But if you have only a few messages, and also other things to configure, a config file would be a good place to do this. > I think the purpose of config files is to provide parameters to a > program or application and not to be used as a repository for > localized versions of program messages. Of course, they could be > used in that way. I suggest that keys in config file meet the Ada > syntax for identifier and be case-insensitive. Ok, thanks for your input. But, I'd like you to think again :). Can you come up with any situation in which you would use Wide_String keys? Do you use Wide_String for anything in your applications? Here in the US, it's easy to think "ASCII solves all problems"; I'd appreciate some input from someone for whom that is not true. > 3. I think that is important to handle more than one config file in > a single program. From my point of view, one of the most important > drawbacks of layouts such as the Windows Registry is that everything > is on a single place so applications that can access to a single > part can also write other parts. In complicated apps it could be > desirable to mantain a set of different config files one for each > part of the application. The ability for handling multiple config > files in a single program should be a requirement for a config file > handling package. Yes, I intend to support this. Please check the draft spec when I post it, to see if it meets these needs. > 4. I don't understand very well the implications of "... specified > by generic parameter at compile time ..." (API req. 5). Does this > mean that the name or the path of the file must be hard coded?. only the defaults; API req 7 allows the application to override these defaults. > If so I think we've missed totally the point (should I recompile > each time I change the name or location of the config file?). The point was that some applications (typically from Gnu and/or Linux) put config files in very standard places, like /usr/local/share. So this default should be compiled in on Linux. However, other applications will want to specify thier own places for config files, so that has to be allowed as well. > 5. Regarding to the file syntax, long time ago I worked on a system > that runs on CAIS (Common APSE Interface Set). > <snip example> > There are, however, some drawbacks in this representation: > > - A escaping schema is needed for unprintable characters in strings > (?). > - Nested '(' and ')' would add a high degree of complexity for the > human user/reader. And it's really only readable for people who know Ada; we'd like this to be useful to a wider audience. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-09 20:54 ` config files proposal Stephen Leake @ 2002-06-10 1:33 ` Darren New 2002-06-10 12:40 ` Stephen Leake 2002-06-11 13:09 ` Ted Dennison 2002-06-13 15:52 ` Georg Bauhaus 1 sibling, 2 replies; 69+ messages in thread From: Darren New @ 2002-06-10 1:33 UTC (permalink / raw) Stephen Leake wrote: > > Configuration tasks are simpler if the config file is commented and > > handling comments is difficult if you use an API call to write to > > the file. > > Good point; I hadn't thought of that. > > I think this makes XML a better idea; we can allow for a "comment" tag > that is saved in the memory image, and written back out. Or simply allow an association of a comment string with each config value. It gets filled in when read, or left out when written. It doesn't take XML to do this. -- This is comment one key1=value1 -- This is comment two key2=value2 -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 1:33 ` Darren New @ 2002-06-10 12:40 ` Stephen Leake 2002-06-10 15:45 ` Darren New 2002-06-11 13:09 ` Ted Dennison 1 sibling, 1 reply; 69+ messages in thread From: Stephen Leake @ 2002-06-10 12:40 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Stephen Leake wrote: > > > Configuration tasks are simpler if the config file is commented and > > > handling comments is difficult if you use an API call to write to > > > the file. > > > > Good point; I hadn't thought of that. > > > > I think this makes XML a better idea; we can allow for a "comment" tag > > that is saved in the memory image, and written back out. > > Or simply allow an association of a comment string with each config value. > It gets filled in when read, or left out when written. The point would be to save the comments in memory, and write them out again. That way, the comments can guide someone hand-editing the file. We might as well let the app write comments via the API as well. > It doesn't take XML to do this. True; Ada can do anything :). -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 12:40 ` Stephen Leake @ 2002-06-10 15:45 ` Darren New 2002-06-11 13:15 ` Ted Dennison 0 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-10 15:45 UTC (permalink / raw) Stephen Leake wrote: > > Or simply allow an association of a comment string with each config value. > > It gets filled in when read, or left out when written. > > The point would be to save the comments in memory, and write them out > again. That way, the comments can guide someone hand-editing the file. Sorry. I meant "written out when written". Sheesh. OK, no more late-night posting for me. My intention was to say that one should be associating comments with keys, not with arbitrary places in the INI file. Then, you wouldn't be restricting yourself to a specific file format that can support (say) multiple independent comments per key. > We might as well let the app write comments via the API as well. I think you need to be careful that you don't make the API too close to file semantics. I.e., you want "here's a data structure, store it", rather than "write this key/value, write this comment, write this other key/value, write another comment, oh and another comment", I would think. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 15:45 ` Darren New @ 2002-06-11 13:15 ` Ted Dennison 2002-06-11 16:36 ` Darren New 0 siblings, 1 reply; 69+ messages in thread From: Ted Dennison @ 2002-06-11 13:15 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3D04C9D0.7DFCED9D@san.rr.com>... > My intention was to say that one should be associating comments with keys, > not with arbitrary places in the INI file. Then, you wouldn't be restricting > yourself to a specific file format that can support (say) multiple > independent comments per key. Yeah, but then you can't make group comments, like: ----------------------------------------------------------- -- The next few items set up system timeout values. Valid -- values range from 0 to 120. The units are in seconds. -- A timeout value of 0 indicates no timeout. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - (temporarily down) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-11 13:15 ` Ted Dennison @ 2002-06-11 16:36 ` Darren New 2002-06-12 7:40 ` Volkert Barr 0 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-11 16:36 UTC (permalink / raw) Ted Dennison wrote: > Yeah, but then you can't make group comments, like: > ----------------------------------------------------------- > -- The next few items set up system timeout values. Valid > -- values range from 0 to 120. The units are in seconds. > -- A timeout value of 0 indicates no timeout. Sure. Any comment more than 76 characters wide gets wrapped on output. > > -- This is comment one > > key1=value1 > > -- This is comment two > > key2=value2 > > True, but it complicates the parsing code significantly, while XML > could handle it easily with some kind of attribute-comment tag. Uh, it does? I don't *think* so. It seems quite straightforward to parse such a thing. My concern with the XML vs INI wrt comments is the possibility that it would make the data structure rather complex. What API do you want to use to say "I want section FOO to have two comments, then key1=value2, then another comment"? All of a sudden, you're not manipulating a collection of keys and values, but rather you're writing out streams of tokens. If each item in the database is a 4-tuple of package, comment, key, value, then it's easy to manipulate. If you start treating the database as a stream of values, where you can have empty sections, sections with only comments, comments with no keys associated, etc, you're going to have a much more complex API for no real good reason other than to make it look like XML. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-11 16:36 ` Darren New @ 2002-06-12 7:40 ` Volkert Barr 2002-06-12 15:45 ` Darren New 2002-06-13 13:38 ` Georg Bauhaus 0 siblings, 2 replies; 69+ messages in thread From: Volkert Barr @ 2002-06-12 7:40 UTC (permalink / raw) Darren New wrote: > > Ted Dennison wrote: > > Yeah, but then you can't make group comments, like: > > ----------------------------------------------------------- > > -- The next few items set up system timeout values. Valid > > -- values range from 0 to 120. The units are in seconds. > > -- A timeout value of 0 indicates no timeout. > > Sure. Any comment more than 76 characters wide gets wrapped on output. > > > > -- This is comment one > > > key1=value1 > > > -- This is comment two > > > key2=value2 > > > > True, but it complicates the parsing code significantly, while XML > > could handle it easily with some kind of attribute-comment tag. > > Uh, it does? I don't *think* so. It seems quite straightforward to parse > such a thing. The problem here is not the parsing of an comment. The problem is to what kind of element the comment belongs. This information is needed, if i want my application to read, manipulate and write an configuration data from/back to a file without losing my comment information. Please, i have set up a small data model, which take this case into count (comment is traditionally called description). Look at http://swt.cs.tu-berlin.de/~barr/config_package.pdf. If such a case should be handled, is is up to us to define a appropriate grammar. Volkert ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-12 7:40 ` Volkert Barr @ 2002-06-12 15:45 ` Darren New 2002-06-13 8:17 ` Volkert Barr 2002-06-13 13:20 ` Ted Dennison 2002-06-13 13:38 ` Georg Bauhaus 1 sibling, 2 replies; 69+ messages in thread From: Darren New @ 2002-06-12 15:45 UTC (permalink / raw) Volkert Barr wrote: > > > True, but it complicates the parsing code significantly, while XML > > > could handle it easily with some kind of attribute-comment tag. > > > > Uh, it does? I don't *think* so. It seems quite straightforward to parse > > such a thing. > The problem here is not the parsing of an comment. Well, that was the problem being discussed, I think. :-) > The problem is to > what > kind of element the comment belongs. That's a good point. Sure, you'd want comments on sections and subsections as well. That still doesn't need XML to implement. > http://swt.cs.tu-berlin.de/~barr/config_package.pdf. Excellent start, I think! -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-12 15:45 ` Darren New @ 2002-06-13 8:17 ` Volkert Barr 2002-06-13 13:20 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Volkert Barr @ 2002-06-13 8:17 UTC (permalink / raw) Darren New wrote: > > Volkert Barr wrote: > > > > True, but it complicates the parsing code significantly, while XML > > > > could handle it easily with some kind of attribute-comment tag. > > > > > > Uh, it does? I don't *think* so. It seems quite straightforward to parse > > > such a thing. > > The problem here is not the parsing of an comment. > > Well, that was the problem being discussed, I think. :-) i had not engough time to follow the thread, so i was a bit ot ouf sync... ;-) > > The problem is to > > what > > kind of element the comment belongs. > > That's a good point. Sure, you'd want comments on sections and subsections > as well. That still doesn't need XML to implement. > > > http://swt.cs.tu-berlin.de/~barr/config_package.pdf. > > Excellent start, I think! I have made an new update! Volkert ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-12 15:45 ` Darren New 2002-06-13 8:17 ` Volkert Barr @ 2002-06-13 13:20 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Ted Dennison @ 2002-06-13 13:20 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3D076CCD.A1F63320@san.rr.com>... > Volkert Barr wrote: > > > > True, but it complicates the parsing code significantly, while XML > > > > could handle it easily with some kind of attribute-comment tag. > > > > > > Uh, it does? I don't *think* so. It seems quite straightforward to parse > > > such a thing. > > The problem here is not the parsing of an comment. > > Well, that was the problem being discussed, I think. :-) No, it wasn't. > > The problem is to > > what > > kind of element the comment belongs. > > That's a good point. Sure, you'd want comments on sections and subsections > as well. That still doesn't need XML to implement. You're almost there. What I was trying to point out is that XML doesn't really support it at all (at least not without adding some kind of "commented-block" tag. Yeeach.). > > http://swt.cs.tu-berlin.de/~barr/config_package.pdf. Out of the 3 options presented there, I think the ".ini" looks the best by far. The others just have way too much syntactic cruft obscuring the important information. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - (temporarily down) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-12 7:40 ` Volkert Barr 2002-06-12 15:45 ` Darren New @ 2002-06-13 13:38 ` Georg Bauhaus 1 sibling, 0 replies; 69+ messages in thread From: Georg Bauhaus @ 2002-06-13 13:38 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> wrote: : Look at : http://swt.cs.tu-berlin.de/~barr/config_package.pdf. Incidentally, for those who would like to have INI files, here is an XSLT: <!-- transform an XML configuration document into a Windows(TM) INI-style configuration text (may need refinements). Cannot handle the nested sections (are there nested sections in the INI file format?). See Volkert Barr's draft --> <transform version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform"> <output method="text"/> <template match="/configuration"> ;Configuration: <value-of select="@name"/> <apply-templates/> </template> <template match="description"> ;<value-of select="normalize-space(.)"/> <!-- line breaking needed here --> </template> <template match="section"> [<value-of select="@name"/>] <apply-templates/> </template> <template match="item"> <value-of select="@*['key']"/>=<apply-templates/> </template> <!-- @*['key'] instead of @key to work around XSLT key() function --> </transform> With input copied from the example in the PDF, the output is ;Configuration: A_Configuration ;bla [A_Section] KeyX=ValueX [A_Subsection] ;bla bla Key1=Value1 Key2=Value2 -- Georg ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-10 1:33 ` Darren New 2002-06-10 12:40 ` Stephen Leake @ 2002-06-11 13:09 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Ted Dennison @ 2002-06-11 13:09 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote in message news:<3D03E1AD.80EB805D@san.rr.com>... > Stephen Leake wrote: > > > Configuration tasks are simpler if the config file is commented and > > > handling comments is difficult if you use an API call to write to > > > the file. > > > > Good point; I hadn't thought of that. > > > > I think this makes XML a better idea; we can allow for a "comment" tag > > that is saved in the memory image, and written back out. > > Or simply allow an association of a comment string with each config value. > It gets filled in when read, or left out when written. It doesn't take XML > to do this. > > -- This is comment one > key1=value1 > -- This is comment two > key2=value2 True, but it complicates the parsing code significantly, while XML could handle it easily with some kind of attribute-comment tag. What you essentially have here is another attribute. One of my 2 things I said we'd have to require out of the config language to make XML a good idea was multiple tags per key. (The other was nested keys). -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-09 20:54 ` config files proposal Stephen Leake 2002-06-10 1:33 ` Darren New @ 2002-06-13 15:52 ` Georg Bauhaus 1 sibling, 0 replies; 69+ messages in thread From: Georg Bauhaus @ 2002-06-13 15:52 UTC (permalink / raw) Stephen Leake <stephen_leake@acm.org> wrote: : I think this makes XML a better idea; we can allow for a "comment" tag : that is saved in the memory image, and written back out. Incidentally, comments aren't lost in XML and each comment belongs to an element. Namely, the element in which it appears. There is a comment() function available to XPath expressions, and a comment element type in XSLT for the creation of comment nodes in the output. (In SGML, things are even fancier. Comments are more Ada like, except at both ends -- like so -- and they can appear in more places than in XML.) -- Georg ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 16:07 config files proposal Stephen Leake 2002-06-02 21:29 ` Darren New 2002-06-04 15:41 ` Antonio Duran @ 2002-06-04 17:06 ` Darren New 2002-06-09 21:01 ` Stephen Leake 2002-06-06 7:57 ` Volkert Barr 2002-06-13 9:08 ` Antonio Duran 4 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-04 17:06 UTC (permalink / raw) And for the folks wanting to use XML for this, here's what the IETF is thinking about using XML. Just an interesting draft. http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-04.txt -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-04 17:06 ` Darren New @ 2002-06-09 21:01 ` Stephen Leake 0 siblings, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 21:01 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > And for the folks wanting to use XML for this, here's what the IETF is > thinking about using XML. Just an interesting draft. > > http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-04.txt Thanks, that looks very interesting. I'll read it later :). -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 16:07 config files proposal Stephen Leake ` (2 preceding siblings ...) 2002-06-04 17:06 ` Darren New @ 2002-06-06 7:57 ` Volkert Barr 2002-06-06 10:04 ` sk ` (2 more replies) 2002-06-13 9:08 ` Antonio Duran 4 siblings, 3 replies; 69+ messages in thread From: Volkert Barr @ 2002-06-06 7:57 UTC (permalink / raw) I have also set up a small document. This should be merged with the work of Mr. Stephen Leake. I tried to contact him, but he did not replyed. Not to mention - this paper is in a very early stage, so it has several errors ;-). Hints and suggestions should be mailed to me (barr@cs.tu-berlin.de) and not to c.l.a. I try to canalize them and send updates to c.l.a. for further discussion. See at: http://swt.cs.tu-berlin.de/~barr/config_package.pdf Volkert ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-06 7:57 ` Volkert Barr @ 2002-06-06 10:04 ` sk 2002-06-06 11:33 ` Volkert Barr 2002-06-07 8:24 ` Volkert 2002-06-09 21:05 ` Stephen Leake 2 siblings, 1 reply; 69+ messages in thread From: sk @ 2002-06-06 10:04 UTC (permalink / raw) Hi, Volkert Barr <barr@cs.tu-berlin.de> > ... of Mr. Stephen Leake. I tried to contact him, but he > did not replyed. ... First message of this thread : Subject: config files proposal Date: Sun, 02 Jun 2002 16:07:53 GMT From: Stephen Leake <stephen_leake@acm.org> > I'm on vacation starting Tuesday (back the following Monday), > so I won't be responding to comments till then. -- ------------------------------------- -- Merge vertically for real address ------------------------------------- s n p @ t . o k i e k c c m ------------------------------------- ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-06 10:04 ` sk @ 2002-06-06 11:33 ` Volkert Barr 2002-06-06 13:56 ` sk 0 siblings, 1 reply; 69+ messages in thread From: Volkert Barr @ 2002-06-06 11:33 UTC (permalink / raw) > First message of this thread : > > Subject: config files proposal > Date: Sun, 02 Jun 2002 16:07:53 GMT > From: Stephen Leake <stephen_leake@acm.org> > > > I'm on vacation starting Tuesday (back the following Monday), > > so I won't be responding to comments till then. sorry! ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-06 11:33 ` Volkert Barr @ 2002-06-06 13:56 ` sk 0 siblings, 0 replies; 69+ messages in thread From: sk @ 2002-06-06 13:56 UTC (permalink / raw) Hi, Nothing to be sorry about. Just thought I would try to save you the anxiety of trying to contact someone who is not there. -- ------------------------------------- -- Merge vertically for real address ------------------------------------- s n p @ t . o k i e k c c m ------------------------------------- ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-06 7:57 ` Volkert Barr 2002-06-06 10:04 ` sk @ 2002-06-07 8:24 ` Volkert 2002-06-07 9:01 ` Jason King 2002-06-09 21:05 ` Stephen Leake 2 siblings, 1 reply; 69+ messages in thread From: Volkert @ 2002-06-07 8:24 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> wrote in message news:<3CFF15E7.9A697B40@cs.tu-berlin.de>... > I have also set up a small document. An updated version can be downloaded! > Hints and suggestions should be mailed to me > (barr@cs.tu-berlin.de) and not to c.l.a. I try to canalize > them and send updates to c.l.a. for further discussion. > > See at: http://swt.cs.tu-berlin.de/~barr/config_package.pdf > > > Volkert ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 8:24 ` Volkert @ 2002-06-07 9:01 ` Jason King 2002-06-07 11:01 ` Preben Randhol ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Jason King @ 2002-06-07 9:01 UTC (permalink / raw) A few thoughts on windows .ini style. 1) The separator for value and key is '=' not ':='. If we use an .ini file it should not break .ini file conventions. 2) Standard .ini files use ';' as a comment to eol indicator, e.g. ; this is a comment [section] real1=val1 ;real2=oldval2 real2=val2 Read/Write functions should ignore the lines that start with a ';'. Volkert wrote: > Volkert Barr <barr@cs.tu-berlin.de> wrote in message news:<3CFF15E7.9A697B40@cs.tu-berlin.de>... > >>I have also set up a small document. > > > An updated version can be downloaded! > > >>Hints and suggestions should be mailed to me >>(barr@cs.tu-berlin.de) and not to c.l.a. I try to canalize >>them and send updates to c.l.a. for further discussion. >> >>See at: http://swt.cs.tu-berlin.de/~barr/config_package.pdf >> >> >>Volkert > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 9:01 ` Jason King @ 2002-06-07 11:01 ` Preben Randhol 2002-06-07 17:06 ` Darren New 2002-06-07 15:07 ` Volkert 2002-06-07 15:12 ` Ted Dennison 2 siblings, 1 reply; 69+ messages in thread From: Preben Randhol @ 2002-06-07 11:01 UTC (permalink / raw) On Fri, 07 Jun 2002 04:01:49 -0500, Jason King wrote: > A few thoughts on windows .ini style. > 1) The separator for value and key is '=' not ':='. If we use an .ini > file it should not break .ini file conventions. > 2) Standard .ini files use ';' as a comment to eol indicator, e.g. > ; this is a comment Yes but on unix it is very common that # is the mark for comments. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 11:01 ` Preben Randhol @ 2002-06-07 17:06 ` Darren New 2002-06-07 17:13 ` Preben Randhol 0 siblings, 1 reply; 69+ messages in thread From: Darren New @ 2002-06-07 17:06 UTC (permalink / raw) Preben Randhol wrote: > > On Fri, 07 Jun 2002 04:01:49 -0500, Jason King wrote: > > A few thoughts on windows .ini style. > > 1) The separator for value and key is '=' not ':='. If we use an .ini > > file it should not break .ini file conventions. > > 2) Standard .ini files use ';' as a comment to eol indicator, e.g. > > ; this is a comment > > Yes but on unix it is very common that # is the mark for comments. If you're going to only allow alphanumberic keys, you might as well accept ; # and -- as comments. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 17:06 ` Darren New @ 2002-06-07 17:13 ` Preben Randhol 2002-06-07 17:33 ` Darren New 0 siblings, 1 reply; 69+ messages in thread From: Preben Randhol @ 2002-06-07 17:13 UTC (permalink / raw) On Fri, 07 Jun 2002 17:06:02 GMT, Darren New wrote: > If you're going to only allow alphanumberic keys, you might as well > accept ; # and -- as comments. Yes thought I would like to have only: -- ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 17:13 ` Preben Randhol @ 2002-06-07 17:33 ` Darren New 2002-06-07 18:26 ` Preben Randhol 2002-06-09 21:08 ` Stephen Leake 0 siblings, 2 replies; 69+ messages in thread From: Darren New @ 2002-06-07 17:33 UTC (permalink / raw) Preben Randhol wrote: > > On Fri, 07 Jun 2002 17:06:02 GMT, Darren New wrote: > > If you're going to only allow alphanumberic keys, you might as well > > accept ; # and -- as comments. > > Yes thought I would like to have only: -- Oh, I should also comment that if you're *not* going to follow the windows .ini file format, chances are the default extension shouldn't be ".ini". :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 17:33 ` Darren New @ 2002-06-07 18:26 ` Preben Randhol 2002-06-09 21:08 ` Stephen Leake 1 sibling, 0 replies; 69+ messages in thread From: Preben Randhol @ 2002-06-07 18:26 UTC (permalink / raw) On Fri, 07 Jun 2002 17:33:53 GMT, Darren New wrote: > Preben Randhol wrote: >> >> On Fri, 07 Jun 2002 17:06:02 GMT, Darren New wrote: >> > If you're going to only allow alphanumberic keys, you might as well >> > accept ; # and -- as comments. >> >> Yes thought I would like to have only: -- > > Oh, I should also comment that if you're *not* going to follow the windows > .ini file format, chances are the default extension shouldn't be ".ini". :-) The package shouldn't care about the filename, just the content. I like the : Program.Name := Glosa Program.Version := 0.8 etc... more than the [Program] Name=Glosa Version=0.8 style too :-) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 17:33 ` Darren New 2002-06-07 18:26 ` Preben Randhol @ 2002-06-09 21:08 ` Stephen Leake 1 sibling, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 21:08 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > Oh, I should also comment that if you're *not* going to follow the windows > .ini file format, chances are the default extension shouldn't be ".ini". :-) note that on Unix, the notion of "file extension" is not built in to the file system as it is on Windows. So I think the API should make no mention of "file extension". -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 9:01 ` Jason King 2002-06-07 11:01 ` Preben Randhol @ 2002-06-07 15:07 ` Volkert 2002-06-07 15:12 ` Ted Dennison 2 siblings, 0 replies; 69+ messages in thread From: Volkert @ 2002-06-07 15:07 UTC (permalink / raw) Jason King <jhking@airmail.net> wrote in message news:<3D00767D.9020100@airmail.net>... > A few thoughts on windows .ini style. What if have done is a "Windows Ini like" definition. > 1) The separator for value and key is '=' not ':='. If we use an .ini > file it should not break .ini file conventions. ok! > 2) Standard .ini files use ';' as a comment to eol indicator, e.g. > ; this is a comment i am with Prebens opinion here. Volkert ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 9:01 ` Jason King 2002-06-07 11:01 ` Preben Randhol 2002-06-07 15:07 ` Volkert @ 2002-06-07 15:12 ` Ted Dennison 2002-06-09 21:16 ` Stephen Leake 2 siblings, 1 reply; 69+ messages in thread From: Ted Dennison @ 2002-06-07 15:12 UTC (permalink / raw) Jason King <jhking@airmail.net> wrote in message news:<3D00767D.9020100@airmail.net>... > A few thoughts on windows .ini style. > 1) The separator for value and key is '=' not ':='. If we use an .ini > file it should not break .ini file conventions. If I can take this as a comment that the above is closer to "true" .ini style, if that's what he was trying to accomplish, then this is a good comment. However, I think it would be a big mistake to make rigid compatability with Windows' .ini files a goal. For one thing, many if not most Ada programs do not run on Windows. For another, that file format is in thrall to Microsoft, and is probably only defined in Microsoft copyrighted documents, if at all. Anything we come up with will have to be something we can define with precision in the new LRM, without having to worry about violating anyone's copyright, or having the format change out from under us at the whim of one (non-Ada) vendor. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - http://www.telepath.com/dennison/Ted/TED.html ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-07 15:12 ` Ted Dennison @ 2002-06-09 21:16 ` Stephen Leake 0 siblings, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 21:16 UTC (permalink / raw) dennison@telepath.com (Ted Dennison) writes: > However, I think it would be a big mistake to make rigid compatability > with Windows' .ini files a goal. For one thing, many if not most Ada > programs do not run on Windows. Possibly true, but not really relevant. If it's a good format, it will be useful on non-Windows systems. Perhaps you are implying "and therefore many people will not be familiar with this format". That is probably true. But it's easy to figure out! > For another, that file format is in thrall to Microsoft, and is > probably only defined in Microsoft copyrighted documents, if at all. > Anything we come up with will have to be something we can define > with precision in the new LRM, without having to worry about > violating anyone's copyright, or having the format change out from > under us at the whim of one (non-Ada) vendor. Hmm. I'm not a copyright lawyer, but it seems like we can simply define a syntax that looks like ini files. As long as we don't actually read Microsoft documents in the process, we should be ok. That's what the MingW people did for the Windows headers files. But we should probably ask a lawyer about that, as has been said about similar topics here recently. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-06 7:57 ` Volkert Barr 2002-06-06 10:04 ` sk 2002-06-07 8:24 ` Volkert @ 2002-06-09 21:05 ` Stephen Leake 2 siblings, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-09 21:05 UTC (permalink / raw) Volkert Barr <barr@cs.tu-berlin.de> writes: > I have also set up a small document. This should be merged with the work > of Mr. Stephen Leake. I tried to contact him, but he did not replyed. I guess I should have mentioned on the web site that I was on vacation :). -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-02 16:07 config files proposal Stephen Leake ` (3 preceding siblings ...) 2002-06-06 7:57 ` Volkert Barr @ 2002-06-13 9:08 ` Antonio Duran 2002-06-13 14:15 ` Stephen Leake 2002-06-13 18:38 ` Ted Dennison 4 siblings, 2 replies; 69+ messages in thread From: Antonio Duran @ 2002-06-13 9:08 UTC (permalink / raw) I would like to raise a question that could be of interest regarding config files. It only must be considered as a discussion point and I am aware of the problems that can convey. Form my point of view, in some cases it could be necessary/interesting to keep configuration information confidential and to provide the means to check the integrity of a configuration file. Should the config file handling requirements make provisions for this circumstances? Antonio Duran ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-13 9:08 ` Antonio Duran @ 2002-06-13 14:15 ` Stephen Leake 2002-06-13 21:04 ` Antonio Duran 2002-06-13 18:38 ` Ted Dennison 1 sibling, 1 reply; 69+ messages in thread From: Stephen Leake @ 2002-06-13 14:15 UTC (permalink / raw) antonio_duran@hotmail.com (Antonio Duran) writes: > Form my point of view, in some cases it could be necessary/interesting > to keep configuration information confidential and to provide the > means to check the integrity of a configuration file. I'm not clear what you mean by "confidential". Clearly, the application program that uses the config file must be able to read it. If you mean that no other process/person should be able to read it, that would be up to the operating system. If the OS provides access controls to files, you can enforce confidentiality. I think that issue has to be outside the scope of the Config_Files API, since it depends heavily on the OS, and we want the Config_Files API to be OS independent. As for checking the integrity of the config file, that could be done with an XML DTD and a validating parser. Come to think of it, that is an advantage of using XML that I had not considered. Although, a non-XML parser could also check integrity to the same degree. Hmm. I'm not clear what you mean by "integrity". XML DTD's allow specifying what values must be present, and to some extent what type they are. In other situations, "integrity" might mean a version control revision number, or a checksum, or something similar. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-13 14:15 ` Stephen Leake @ 2002-06-13 21:04 ` Antonio Duran 2002-06-14 16:15 ` Stephen Leake 0 siblings, 1 reply; 69+ messages in thread From: Antonio Duran @ 2002-06-13 21:04 UTC (permalink / raw) Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> wrote in message news:<uu1o7uuw1.fsf@gsfc.nasa.gov>... > antonio_duran@hotmail.com (Antonio Duran) writes: > > > Form my point of view, in some cases it could be necessary/interesting > > to keep configuration information confidential and to provide the > > means to check the integrity of a configuration file. > > I'm not clear what you mean by "confidential". Clearly, the > application program that uses the config file must be able to read it. > > If you mean that no other process/person should be able to read it, > that would be up to the operating system. If the OS provides access > controls to files, you can enforce confidentiality. > > I think that issue has to be outside the scope of the Config_Files > API, since it depends heavily on the OS, and we want the Config_Files > API to be OS independent. > > > As for checking the integrity of the config file, that could be done > with an XML DTD and a validating parser. Come to think of it, that is > an advantage of using XML that I had not considered. Although, a > non-XML parser could also check integrity to the same degree. > > Hmm. I'm not clear what you mean by "integrity". XML DTD's allow > specifying what values must be present, and to some extent what type > they are. > > In other situations, "integrity" might mean a version control revision > number, or a checksum, or something similar. What I meant with confidentiality and integrity was to use cryptographic technics to encrypt/decrypt config files for confidentiality and hash/digest for checking integrity. I know this is far beyond the scope since by using that the file couldn't be modified by hand with a simple text editor. My intent was to know if that kind of functionality could be of interest in some circumstances. Antonio Duran ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-13 21:04 ` Antonio Duran @ 2002-06-14 16:15 ` Stephen Leake 0 siblings, 0 replies; 69+ messages in thread From: Stephen Leake @ 2002-06-14 16:15 UTC (permalink / raw) antonio_duran@hotmail.com (Antonio Duran) writes: > What I meant with confidentiality and integrity was to use > cryptographic technics to encrypt/decrypt config files for > confidentiality and hash/digest for checking integrity. Ok, that's clear. > I know this is far beyond the scope since by using that the file > couldn't be modified by hand with a simple text editor. Yes. > My intent was to know if that kind of functionality could be of > interest in some circumstances. Not to me, but it's a good question. -- -- Stephe ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: config files proposal 2002-06-13 9:08 ` Antonio Duran 2002-06-13 14:15 ` Stephen Leake @ 2002-06-13 18:38 ` Ted Dennison 1 sibling, 0 replies; 69+ messages in thread From: Ted Dennison @ 2002-06-13 18:38 UTC (permalink / raw) antonio_duran@hotmail.com (Antonio Duran) wrote in message news:<e1a50f2.0206130108.995ef66@posting.google.com>... > Form my point of view, in some cases it could be necessary/interesting > to keep configuration information confidential and to provide the > means to check the integrity of a configuration file. > > Should the config file handling requirements make provisions for this > circumstances? No. It sounds to me like you are arguing for an encryption/decryption package. Then you could add use of it on certian keys as an option. That might be a good discussion, but something as involved as encryption wouldn't belong in a config file package. Or are you just talking about "password" type data? Most OS's have special calls to deal with that type of data. I suppose it would be possible to write some kind of one-way encoding function in Ada. However, that should still probably be in its own package. -- T.E.D. Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison) Homepage - (temporarily down) ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2002-06-14 16:15 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-02 16:07 config files proposal Stephen Leake 2002-06-02 21:29 ` Darren New 2002-06-02 22:00 ` Darren New 2002-06-02 22:16 ` Stephen Leake 2002-06-03 4:20 ` Darren New 2002-06-09 20:16 ` Stephen Leake 2002-06-10 1:33 ` Darren New 2002-06-10 12:35 ` Stephen Leake 2002-06-10 15:42 ` Darren New 2002-06-10 14:23 ` Georg Bauhaus 2002-06-03 14:56 ` Ted Dennison 2002-06-03 16:08 ` Darren New 2002-06-03 16:24 ` Jean-Marc Bourguet 2002-06-03 16:50 ` Darren New 2002-06-04 11:07 ` Preben Randhol 2002-06-04 19:55 ` Ted Dennison 2002-06-09 20:43 ` Stephen Leake 2002-06-09 20:39 ` Stephen Leake 2002-06-10 1:33 ` Darren New 2002-06-10 10:17 ` Preben Randhol 2002-06-09 20:29 ` Stephen Leake 2002-06-10 1:33 ` Darren New 2002-06-10 18:58 ` Ted Dennison 2002-06-11 18:11 ` Stephen Leake 2002-06-03 15:13 ` Preben Randhol 2002-06-04 15:41 ` Antonio Duran 2002-06-04 15:51 ` Darren New 2002-06-05 10:17 ` Antonio Duran 2002-06-05 14:31 ` Ted Dennison 2002-06-05 19:12 ` Syntactically correct spanish identifiers (Was: config files proposal) Jacob Sparre Andersen 2002-06-06 1:49 ` Robert Dewar 2002-06-07 8:07 ` Antonio Duran 2002-06-07 15:37 ` Robert Dewar 2002-06-09 20:54 ` config files proposal Stephen Leake 2002-06-10 1:33 ` Darren New 2002-06-10 12:40 ` Stephen Leake 2002-06-10 15:45 ` Darren New 2002-06-11 13:15 ` Ted Dennison 2002-06-11 16:36 ` Darren New 2002-06-12 7:40 ` Volkert Barr 2002-06-12 15:45 ` Darren New 2002-06-13 8:17 ` Volkert Barr 2002-06-13 13:20 ` Ted Dennison 2002-06-13 13:38 ` Georg Bauhaus 2002-06-11 13:09 ` Ted Dennison 2002-06-13 15:52 ` Georg Bauhaus 2002-06-04 17:06 ` Darren New 2002-06-09 21:01 ` Stephen Leake 2002-06-06 7:57 ` Volkert Barr 2002-06-06 10:04 ` sk 2002-06-06 11:33 ` Volkert Barr 2002-06-06 13:56 ` sk 2002-06-07 8:24 ` Volkert 2002-06-07 9:01 ` Jason King 2002-06-07 11:01 ` Preben Randhol 2002-06-07 17:06 ` Darren New 2002-06-07 17:13 ` Preben Randhol 2002-06-07 17:33 ` Darren New 2002-06-07 18:26 ` Preben Randhol 2002-06-09 21:08 ` Stephen Leake 2002-06-07 15:07 ` Volkert 2002-06-07 15:12 ` Ted Dennison 2002-06-09 21:16 ` Stephen Leake 2002-06-09 21:05 ` Stephen Leake 2002-06-13 9:08 ` Antonio Duran 2002-06-13 14:15 ` Stephen Leake 2002-06-13 21:04 ` Antonio Duran 2002-06-14 16:15 ` Stephen Leake 2002-06-13 18:38 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox