Re: Where does your APL application hold its settings?
- From: "J. Clarke" <jclarke.usenet@xxxxxxxxxxxxxxxx>
- Date: Sun, 05 Feb 2006 23:41:16 -0500
Mike Kent wrote:
J. Clarke wrote:
Mike Kent wrote:
This is why one uses conditional compilation. Put it in HKLM and HKCU on
Windows and ~.<whatever> or /etc/<whatever> on Linux systems and wherever
the accepted practices call for on other Unix variants.
It's called "portability" and it can be a bitch.
Less so, frequently, if you avoid platform-specific facilities when
you reasonably can.
If you are going to "avoid platform specific facilities" then you're going
to be pretty much restricted to a command line.
Beyond that, I don't see it as harder to write
utility functions that read/write configuration from files than to
implement the
same interface using a registry, or a database.
It's not harder, it's not easier, but you're creating headaches for
administrators if they have to dig in your docs to figure out the
non-standard thing that you did.
Whereas they would /not/ have to look at the docs to suss stuff out out
if the Windows registry keys is used? The keys are easy to find and to
distinguish from the zillion keys for other things, and the acceptable
values are self-evident?
No, actually, they wouldn't if you did a reasonable job of naming the keys,
with perhaps your company name then the application name then the
application-specific keys.
As you say, "It's not harder, it's not easier".
...
"Last open file" etc would be an appropriate use of the registry,
putting the whole file there would not.
I would separate the state preservation interface from the configuration
interface -- they are separate concerns -- but OK, yes it is better to
store a file name than to store a copy of a file. Perhaps a bit more
fragile
So what do you propose to do, hardwire the location of the file into your
application?
???
The name of the last open file? The need does not exist in the app I
support at work; if it did, I might indeed associate the filename with a
known (hardwired) key in a known (hardwired) persistent associative store.
And, unless there were a compelling reason to do otherwise, I would use a
generically available type of persistent store.
And where would this "persistent store" be kept? I'm sorry, but you're
weaseling here.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)
.
- Follow-Ups:
- Re: Where does your APL application hold its settings?
- From: Mike Kent
- Re: Where does your APL application hold its settings?
- References:
- Re: Where does your APL application hold its settings?
- From: Mike Kent
- Re: Where does your APL application hold its settings?
- From: Mike Kent
- Re: Where does your APL application hold its settings?
- From: Mike Kent
- Re: Where does your APL application hold its settings?
- From: J. Clarke
- Re: Where does your APL application hold its settings?
- From: Mike Kent
- Re: Where does your APL application hold its settings?
- From: J. Clarke
- Re: Where does your APL application hold its settings?
- From: Mike Kent
- Re: Where does your APL application hold its settings?
- Prev by Date: Re: Where does your APL application hold its settings?
- Next by Date: Re: Where does your APL application hold its settings?
- Previous by thread: Re: Where does your APL application hold its settings?
- Next by thread: Re: Where does your APL application hold its settings?
- Index(es):
Relevant Pages
|