Some useful thoughts, thanks... The scale and "interface" (such that it is) is an issue, though.... and warrants some further explanation of what we're dealing with...
An example of a (tiny) section:-
123: A1=12:MSMA=32:PX=2: RP=12,23:
Currently, there are ~12,000 sections (each containing perhaps up to 100 lines of code, similar to that shown above), with many 100s of the sections being unused at any given time. At most, there can be something like 65,000 entries in this plain text file... and the sections need to be managed manually - there is no control/dependency enforced regarding the section and the application "module" that refers to it; in fact, many modules can refer to the section, in a number of ways... but you have to know the modules that refer to the section - there is nothing in the application which provides the "reverse link". The application provides a very rudimentary text editor (not as useful as a Windows "Notepad") to maintain the text file in which these sections are stored.
The application is something that's moved between platforms (PDP/RSX -> VAX/VMS -> PC/Windows) during the last 40+ years it's been in use... so the text file has been managed with line editors, external screen editors and now has its own "internal" text editor... but the basic design/structure hasn't changed - the software vendor considers this "interface" as adequate for managing all the sections.
Hence, having very many "unused" sections introduces a lot of "noise" when trying to locate sections, examine the contents of the sections, etc... and as every section is "free-form" text (more-or-less), most people who have used the file over the years have never added useful identifiers to the sections (such as author, date of use, what other components of the application *use* the section, application notes of the section, etc) which help to decide whether the section is in-use, critical, expired, etc, although there has always been the concept of a "comment line" - it's simply that most users have decided to rarely use any comments(!)
Sure, we have built some tools to help us check the dependencies, the contents of the sections, etc... but the users still tend to want to be able to see "all" of the sections they might be interested in collected together in the one place in the file (perhaps 10 or more, 100-line sections)... and want to have them ALL in the file "just in case". Others find it annoying to have to work through each individual section, finding some to be "unused", when they're trying to find specific code within each section... or, indeed, to locate a particular section they might want to work on.
Anyway, we have to get the files "cleaned-up" (there are currently 30+ of these files), removing unused sections, perhaps introducing some decent comments, etc... but some users agree to ACTUAL removal of the unused sections (the files are backed-up and are available on-line every day for the last rolling 2 years) and some want to keep everything in the file, even though the sections may become irrelevant over the time that elapses between uses ...and we're just looking to see if there's any approach to such a text file that's considered "good practice" when "removing" sections from the file... hence my weird question.
In reply to Re: [OT] What is 'Good Practice' use of an .ini/.conf file: Database or Active Document?
by ozboomer
in thread [OT] What is 'Good Practice' use of an .ini/.conf file: Database or Active Document?
by ozboomer
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |