APL - Where does your APL application hold its settings?

Author

Where does your APL application hold its settings?

AA2e72E

2006-02-02, 6:56 pm

By settings, I mean working paths, state of the application on last exit,
most recently used files etc. of the application and NOT the APL runtime.
The obvious choices are the Registry, INI, or XML files. If any of these,
do you use API calls to read/write from these?
An eligible choice is a component file in the same folder as your APL
runtime workspace. I am sure others choices are viable.
OR: Do your APL applications start in exactly the same way as it did the
first time and does not adapt to the users' choices of <anything>, like
lsat working folder?

ashepp0@gmail.com

2006-02-02, 9:55 pm

For myself, running a stateless app, I put color, []CT, []RL, []IO,
etc. plus the name of the main routine, in a function called LX, and
error trapping mechanisms in ELX, then I store like: []LX<-'ELX <> LX'
right in the workspace.

/A. Shepp
ashepp0@gmail.com

David Liebtag

2006-02-02, 9:55 pm

APL2 includes some cover functions which make it easy to store and retrieve
application settings. The functions currently only work on Windows and
store the data in the registry, but I would like to enhance them to work on
other operating systems too.

David Liebtag
IBM APL Products and Services

Dick Bowman

2006-02-03, 3:55 am

"AA2e72E" <aa2e72e@deletethisword.lycos.co.uk> wrote in
news:9ad61b7a2a3880c236d9e916e1542732
@localhost.talkaboutprogramming.com:

> By settings, I mean working paths, state of the application on last
> exit, most recently used files etc. of the application and NOT the APL
> runtime. The obvious choices are the Registry, INI, or XML files. If
> any of these, do you use API calls to read/write from these?
> An eligible choice is a component file in the same folder as your APL
> runtime workspace. I am sure others choices are viable.
> OR: Do your APL applications start in exactly the same way as it did
> the first time and does not adapt to the users' choices of <anything>,
> like lsat working folder?
>
>
>

I've used several approaches, at the moment (with Dyalog APL) I prefer
using a component file to hold settings along with a startup parameter
(in the application shortcut command line) to say what the file is
called.

Combining this approach with a bit of utility code (all contained in a
single namespace) gets me a way of handling application configuration
which ports easily to new applications and is easily extendable.

I could probably wrap the code around any of the above, if I felt there
was a better way to go.

I prefer to keep away from the registry (it's a juggernaut, everything
else is in there, I like to minimise my application footprint, and it
doesn't seem portable to other worlds - some day Windows will reach the
end of the road).

INI files (and XML) seemed to have the benefit that they are ASCII,
hence editable outside of APL (but maybe that's also a drawback). But
they're also outside the APL idiom, and if the goal is to put some data
into an APL variable (or get it out of an APL variable) then a component
file feels like a natural fit.

The only thing that makes me uneasy about using component files is that
they're one more thing that needs converting when moving from one APL to
another - and I like to try and keep my options open.

But people and applications have different preferences - my approach
suits me.

AA2e72E

2006-02-08, 9:02 am

I find that while it is easy to read and write applications setting to the
Registry, it is client bound: i.e. for a network based application where
users 'inherit' work from colleages, do not also implicitly 'inherit;
their registry settings.
One workaround is to use INI (or XML) files (stored in the working path):
then on 'inheriting' work, its last state is available.
The component file approach is basically the same as the INI approach: the
diference is that the component file protects its contents better.

Why not use a database for this purpose? It will make the application
settings APL neutral.

PM Hager

2006-02-08, 9:02 am

If your questions regards complete applications, there are more aspects
to consider, than just where to store application settings.

>From a computer's view, settings regarding your application's location,
shortcuts, uninstallation etc. need to be stored. There are several
installer programs doing a good job. (My personal preference still is
InstallShield Express, as it is quick and easily to configure. But
there are quite a few on par with it.)

As such installers widely use the registry and remove themselves upon
uninstallation, I prefer this location for application settings as
well, because those entries can easily get included into an uninstall
cleanup.

All you need to take account of, is to use the path
" HKEY_CURRENT_USER\Software\Vendor\Applic
ation" for individual user
settings, and " HKEY_LOCAL_MACHINE\Software\Vendor\Appli
cation" for
machine-wide settings. To give an example:

HKEY_CURRENT_USER\Software\MyName\MyApp\
ProtocolPrint
DevMode REG_BINARY ...
Margin REG_BINARY ...
Pages REG_BINARY ...

HKEY_LOCAL_MACHINE\Software\MyName\MyApp
\AutoUpdate
Enabled REG_DWORD 1
Url REG_SZ "http:.."

Registry's di

vantage of course is, that it is a proprietary windows
facility. It only makes sense to use it, when you do not plan to port
the application to other platforms. Advantages are:

hierarchical structure (also xml- and component-file),
named objects (also ini- and xml-file),
typed objects (also component-file) and
on-board editor (also ini-file).

Ray Powell

2006-02-08, 9:02 am

I use INI files via API calls. APLX for Windows:
⍝ Write: value INIString "section" "entry" "file"
"WriteString" ⎕na "U Kernel32|WritePrivateProfileStringA <C[256] <C[256] <C[256]
<C[256]"
⍝
⍝Read: R←INIString "section" "entry" "default" "file"
"ReadString" ⎕na "U Kernel32|GetPrivateProfileStringA <C[256] <C[256] <C[256]
>C[256] <I <C[256]"

AA2e72E wrote:
> By settings, I mean working paths, state of the application on last exit,
> most recently used files etc. of the application and NOT the APL runtime.
> The obvious choices are the Registry, INI, or XML files. If any of these,
> do you use API calls to read/write from these?
> An eligible choice is a component file in the same folder as your APL
> runtime workspace. I am sure others choices are viable.
> OR: Do your APL applications start in exactly the same way as it did the
> first time and does not adapt to the users' choices of <anything>, like
> lsat working folder?
>
>
>

--
email: ray dot powell at shaw dot ca
--
Ray Powell
Victoria, BC.
Canada

Mike Kent

2006-02-08, 9:02 am

AA2e72E wrote:
> By settings, I mean working paths, state of the application on last exit,
> most recently used files etc. of the application and NOT the APL runtime.
> The obvious choices are the Registry, INI, or XML files. If any of these,
> do you use API calls to read/write from these?
> An eligible choice is a component file in the same folder as your APL
> runtime workspace. I am sure others choices are viable.
> OR: Do your APL applications start in exactly the same way as it did the
> first time and does not adapt to the users' choices of <anything>, like
> lsat working folder?

For a lot of (? most) in-house applications, notions like "last working
folder" even don't come up, and not uncommonly there is no user state that
has to be saved across settings.

For cases where there is, I am surprised by the willingness shown here to
use field artillery to kill flies -- databases, XML, the Windows registry
(shudder). For many cases, simple ASCII text files in a "well-known"
location (say "/etc") are mostly enough -- just a sequence of records of
the form

name = value

and local convention that says the '#' symbol is like an APL comment lamp,
it and everything to its right are ignored.

I may be somewhat biased by the fact that our shop is Unix-based and the
above is probably the most common way to configure Unix apps and tools ...

Dick Bowman

2006-02-08, 9:02 am

"AA2e72E" <aa2e72e@deletethisword.lycos.co.uk> wrote in
news:9c4daec5bc8fc4b853e3a0bc1bb7fe38@lo
calhost.talkaboutprogramming.com:

> [... deleted ...]
> The component file approach is basically the same as the INI approach:
> the diference is that the component file protects its contents better.
>
> Why not use a database for this purpose? It will make the application
> settings APL neutral.
>

A significant factor (for me, at least) is that component files can contain
APL variables of arbitrary shape and type, which are retrievable from a
workspace (and restorable into it) with no mental effort.

AA2e72E

2006-02-08, 9:02 am

It is precisely that: storing and retrieving name-value pairs and coercing
an application into one of its pathways.
ASCII files (being sequential)carry a big overhead; INI files are better
as you can read them with simple API calls (do all the work) on Windows,
likewise XML files which are platform independent.
If APL data is not involved, a database is probably the most suitable
store for an applications settings: I wondered whether anyone used them.
I am surprised that you find no need to restore an application to its last
known state: besides being polite, it is often necessary in a multiuser
client/server application where users often resume from/delegate one
another's work in progress, often in different folders.

Mike Kent

2006-02-08, 9:02 am

Summarizing what's below ...

most configuration is simple

simple means are appropriate to simple tasks

So:

AA2e72E wrote:
> It is precisely that: storing and retrieving name-value pairs and coercing
> an application into one of its pathways.

OK so far.

> ASCII files (being sequential)carry a big overhead;

???

You have to read and parse the file once per session. I would not expect
this to be "a big overhead" under most circumstances; it takes a fraction
of a second to deserialize such a file into a dictionary structure in the
workspace and about the same to serialize the dictionary to file.

> INI files are better as you can read them with simple API calls
> (do all the work) on Windows,

I guess. This is not really an option outside of windows, and if
you exchange one name for one value per API call, I would expect the
(still negligible) overhead to be higher than reading in a simple
configuration file. If you do these exchanges repeatedly as the
application executes, I suppose you might actually introduce enough
overhead that it matters.

> likewise XML files which are platform independent.

This is getting into the serious-overkill arena. It is not particularly
difficult to write a parser for simple XML (non-validating, ignoring
attributes, character entities, CDATA) in APL, producing a DOM-tree-like
datum in the workspace, but them you need tree-traversal utilities to get
actual data in and out ... . Learning how to use any of the various APIs
for this (other than .NET which looks to be easy-ish if you're in Windows
and your APL is .NET-aware) is a bit of an undertaking as well.

OTOH, once able to handle the XML for configuration, you are likely to be
ready to use XML for other purposes as well, and that's useful.

> If APL data is not involved,

Neither of the approaches above are especially well-suited to "APL data",
if by that you mean large or highly-structured arrays.

> a database is probably the most suitable
> store for an applications settings:

If the application requires access to a DB anyway, putting simple config
into a DB table may make sense. Hauling a DB into an application solely for
this purpose seems excessive.

> I wondered whether anyone used them.
> I am surprised that you find no need to restore an application to its last
> known state: besides being polite, it is often necessary in a multiuser
> client/server application where users often resume from/delegate one
> another's work in progress, often in different folders.

For some kinds of applications. In many cases it is sufficient to preserve
the state of the work (and for this purpose database or component files are
likely to be good ways to persist the data). In any cast, preserving work-
in-process is not what I would understand by "configuration", and as a
separate concern, should ordinarily be separately addressed.

Mike Kent

2006-02-08, 9:02 am

Dick Bowman wrote:

> A significant factor (for me, at least) is that component files can contain
> APL variables of arbitrary shape and type, which are retrievable from a
> workspace (and restorable into it) with no mental effort.

I can certainly see this if you are preserving a lot of data or data with a
lot of structure ... but for simple config?

AA2e72E

2006-02-08, 9:02 am

<Most configuration is simple> : I supose it depends on how you define
simple. Comsider this scenario: 3 versions of an application exist in the
field, in between the penultimate third and the current, the application
has changed its structure. The current version 'silently' brings previous
structues up to date. How do you identify the 'existing' version and drive
the current application to update it to the current structure without tags
as regards the existing version? In case this is not obvious, the third
penultimate version includes neither 'Pension protection fund' changes nor
'simplification' changes but the current version includes both and may
encounter other version with or without either or both sets of changes.
[The background in pensions legislation in the UK].
<You only have to read it one per session> Not so. I can switch from
[Client1] that has none of the changes to [client2] that has one of the
changes to [client3] that has both: my current version needs to know where
it is and what it has to do.

Ibeam2000

2006-02-08, 9:02 am

The one time I needed to do this, I tried to choose something which I
thought would be "natural" for the operating system at hand, which was,
that day, Windoze NT. Thus the choice was Windows Registry. Although
the information was not in any way secret, the Windoze Registry does
not invite snooping, at least for the class of user we have using the
application. An "APPL.INI" file would be browsed (and at worst,
accidently deleted). From a privacy point of view, registry entries
were perceived to be acceptable while an entry in a database might not.

On Unix, I might park a config file in some less-than-obvious location.

I suppose it would be easy enough to write a "registry" for non-Windoze
systems, using some primitive single-file database and complete with
lookalike api functions.

Dick Bowman

2006-02-08, 9:02 am

Mike Kent <mkent@acm.org> wrote in news:44jusvF2jmsgU1@individual.net:

> Dick Bowman wrote:
>
>
> I can certainly see this if you are preserving a lot of data or data
> with a lot of structure ... but for simple config?

It can happen...

Mike Kent

2006-02-08, 9:02 am

AA2e72E wrote:
> <Most configuration is simple> : I supose it depends on how you define
> simple. Comsider this scenario: 3 versions of an application exist in the
> field, in between the penultimate third and the current, the application
> has changed its structure. The current version 'silently' brings previous
> structues up to date. How do you identify the 'existing' version and drive
> the current application to update it to the current structure without tags
> as regards the existing version? In case this is not obvious, the third
> penultimate version includes neither 'Pension protection fund' changes nor
> 'simplification' changes but the current version includes both and may
> encounter other version with or without either or both sets of changes.
> [The background in pensions legislation in the UK].

When I was talking about "configuration", I was referring to data that can
be changed to control application behavior /without/ changing the software
itself. In that context, the software version identifier would not be
"configuration". But what ho, why not allow it? I still don't see that
you need a registry entry to store a string like "FuBarCo APL App V3.1.6".

> <You only have to read it one per session> Not so. I can switch from
> [Client1] that has none of the changes to [client2] that has one of the
> changes to [client3] that has both: my current version needs to know where
> it is and what it has to do.

Unless you do this repeatedly at intervals shorter than about 10 seconds,
the overhead of importing a couple dozen config settings should not amount
as much as 1% of your elapsed time.

The cost of dealing with the fact that configuration has changed, which may
certainly be substantial, is another matter; I don't see how the mechanics
of storing the configuration affect it, though.

Perhaps you are including preservation of work-in-process under the rubric
of "configuration"? I don't think so; I can't imagine that anyone would
suggest saving that kind of data in (e.g.) the Windows registry.

AA2e72E

2006-02-08, 9:02 am

I guess you are the ultimate guardian of the APL 'Comfort Zone': everything
has to be done with APL and using native APL facilities.

J. Clarke

2006-02-08, 9:02 am

Mike Kent wrote:

> AA2e72E wrote:
>
> When I was talking about "configuration", I was referring to data that can
> be changed to control application behavior /without/ changing the software
> itself. In that context, the software version identifier would not be
> "configuration". But what ho, why not allow it? I still don't see that
> you need a registry entry to store a string like "FuBarCo APL App V3.1.6".

You don't _need_ a registry entry to do _anything_, but why _not_ use one?
It's what the registry is there for. Never ceases to amaze me the lengths
that people will go to to fight the system.

>
> Unless you do this repeatedly at intervals shorter than about 10 seconds,
> the overhead of importing a couple dozen config settings should not amount
> as much as 1% of your elapsed time.
>
> The cost of dealing with the fact that configuration has changed, which
> may certainly be substantial, is another matter; I don't see how the
> mechanics of storing the configuration affect it, though.
>
> Perhaps you are including preservation of work-in-process under the rubric
> of "configuration"? I don't think so; I can't imagine that anyone would
> suggest saving that kind of data in (e.g.) the Windows registry.

"Last open file" etc would be an appropriate use of the registry, putting
the whole file there would not.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

J. Clarke

2006-02-08, 9:02 am

AA2e72E wrote:

> <Most configuration is simple> : I supose it depends on how you define
> simple. Comsider this scenario: 3 versions of an application exist in the
> field, in between the penultimate third and the current, the application
> has changed its structure. The current version 'silently' brings previous
> structues up to date. How do you identify the 'existing' version and drive
> the current application to update it to the current structure without tags
> as regards the existing version? In case this is not obvious, the third
> penultimate version includes neither 'Pension protection fund' changes nor
> 'simplification' changes but the current version includes both and may
> encounter other version with or without either or both sets of changes.
> [The background in pensions legislation in the UK].
> <You only have to read it one per session> Not so. I can switch from
> [Client1] that has none of the changes to [client2] that has one of the
> changes to [client3] that has both: my current version needs to know where
> it is and what it has to do.

In this case, you're kind of stuck unless the developer of the _original_
version conveniently stuck in a version tag on the data files somewhere.

That's not an issue of "configuration" so much as version control--Microsoft
and Novell run into it all the time with their directory services and one
of the rules is that you update the schema before you update the directory
service otherwise all Hell breaks out.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

AA2e72E

2006-02-08, 9:02 am

<It's what the registry is there for. Never ceases to amaze me the lengths
that people will go to to fight the system.> I too felt that Mike was
fighting ...

Any registry value cannot exceed 256 bytes, so it can be used for system
markers : not just because it is there but especially because other
applications can use them. For example, if someone wants to use the last
budget forecast figures file (XLS, created by an APL application with
automationthat also wrote the name of the file to the registry), they can
by simply reading the key that holds the file name.

My own feeling is that we should use Windows resources (Registry, API etc)
for 3 very strong reasons: 1. It avoids self-indulgent APL
re-inventions/overheads. 2. It endows APL the same interface
characteristics as other applications to which users are more accustomed.
and 3. ALL the APL providers have empowered their developers to use
Windows resources: why are developers so scared to venture out of the pool
called WORKSPACE?

David Liebtag

2006-02-08, 9:02 am

AA2E72E (who I wish would sign his or her name so we knew who we were
talking to) wrote:

> Any registry value cannot exceed 256 bytes,

What makes you think that? The Microsoft Platform SDK description of the
RegSetValueEx API states:

Value sizes are limited by available memory. Long values (more than 2048
bytes) should be stored as files with the file names stored in the registry.
This helps the registry perform efficiently. Application elements such as
icons, bitmaps, and executable files should be stored as files and not be
placed in the registry.

David Liebtag

AA2e72E

2006-02-08, 9:02 am

Thank you for putting me right on the maximum size of a value in the
registry.
[I don't know where I picked up the 256 limit?]

I'll research this soon: I expect there would be different limits
depending on data type, REG_SZ, REG_DWORD etc.

Have you got a link for the SDK context that you quoted?

AA

Mike Kent

2006-02-08, 9:02 am

AA2e72E wrote:
> I guess you are the ultimate guardian of the APL 'Comfort Zone': everything
> has to be done with APL and using native APL facilities.

Not at all.

Mike Kent

2006-02-08, 9:02 am

J. Clarke wrote:
> Mike Kent wrote:
>
....
>
>
> You don't _need_ a registry entry to do _anything_, but why _not_ use one?
> It's what the registry is there for. Never ceases to amaze me the lengths
> that people will go to to fight the system.

Well, in my case, I /can't/ use the registry; it does not work very well
on our Un*x systems. 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. And I would /not/ put the
code that does the low-level work into the application without wrapping it
in utilities.

> "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 ...

Mike Kent

2006-02-08, 9:02 am

AA2e72E wrote:
> <It's what the registry is there for. Never ceases to amaze me the lengths
> that people will go to to fight the system.> I too felt that Mike was
> fighting ...

I guess you missed the part upthread where I pointed out that

the apps I support do not run on Windows

so in this case, doing a technically trivial job in a technically
trivial (and highly portable) way is perhaps not exactly "fighting
the system".

AA2e72E

2006-02-08, 9:02 am

I have little relevant experience of how things are on other platforms.
However, if I were working with APLX and sought to preserve
portability/platform independence, I would be inclined to adopt Mike
Kent's approach: that is, use component files (random read/write,
preserves APL data etc).
The trouble with this is that you soon have a lot of files, and therefore
a lot of versions etc. It will only take one of those files to be out of
step (on moving or re-installation) and the whole thing will come
trashing
down.
My preferred approach would be to build an application comprising of
just
2 things: a small workspace PLUS a database. Everything gets stored in
the
database, including custom (such as component files) & text files etc,
workspace variables, functions etc. A database can store like named
objects if the name of the object and one or more keys are used.
At run time, the workspace extracts its requirements & reconstitutes
itself (to any configuration)-on a needs basis.
I have tested this approach with APL+Win and Oracle/SQL Server (I think
DB2 & SQL Anywhere would be ok too): it works very well. With APLX, it
works but not quite as well with files: I am still investigating.
Do you know if a C# DLL compiled on Windows will run on Unix/Linux: I
hear
that Mono has come a long way. If it does, it would make everything so
easy: APL will just have to call the DLL functionality that can take care
of all the nasty bits.

J. Clarke

2006-02-08, 9:02 am

Mike Kent wrote:

> J. Clarke wrote:
> ...
>
> Well, in my case, I /can't/ use the registry; it does not work very well
> on our Un*x systems.

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 XXXXX.

> 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.

> And I would /not/ put the
> code that does the low-level work into the application without wrapping it
> in utilities.
>
>
> 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?

> ...

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

J. Clarke

2006-02-08, 9:02 am

Mike Kent wrote:

> AA2e72E wrote:
>
> I guess you missed the part upthread where I pointed out that
>
> the apps I support do not run on Windows

Well if the apps you support do not run on Windows the the registry is
non-issue so why are you even opining about it?

> so in this case, doing a technically trivial job in a technically
> trivial (and highly portable) way is perhaps not exactly "fighting
> the system".

"Highly portable"? So tell me the portable path names for your
configuration files.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

Mike Kent

2006-02-08, 9:02 am

AA2e72E wrote:

> However, if I were working with APLX and sought to preserve
> portability/platform independence, I would be inclined to adopt Mike
> Kent's approach: that is, use component files (random read/write,
> preserves APL data etc).

I think you mean "Dick Bowman's approach".

> The trouble with this is that you soon have a lot of files,

.... a lot of registry keys,

> and therefore
> a lot of versions etc. It will only take one of those files to be out of
> step (on moving or re-installation)

.... It will take only one of those registry keys to be out of step ...

Mike Kent

2006-02-08, 9:02 am

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 XXXXX.

Less so, frequently, if you avoid platform-specific facilities when
you reasonably can.

>
>
> 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?

As you say, "It's not harder, it's not easier".

....
>
>
> 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.

David Liebtag

2006-02-08, 9:02 am

I actually quoted the text from the Microsoft Visual Studio documentation.
But, it's available online in the MSDN. Googling for RegSetValueExe and
selecting the first hit will take you right there:
http://msdn.microsoft.com/library/d...gsetvalueex.asp

David Liebtag

J. Clarke

2006-02-08, 9:02 am

Mike Kent wrote:

> J. Clarke wrote:
>
>
> 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.

>
> 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".
>
> ...
>
> ???
>
> 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)

J. Clarke

2006-02-08, 9:02 am

AA2e72E wrote:

> I have little relevant experience of how things are on other platforms.
> However, if I were working with APLX and sought to preserve
> portability/platform independence, I would be inclined to adopt Mike
> Kent's approach: that is, use component files (random read/write,
> preserves APL data etc).
> The trouble with this is that you soon have a lot of files, and therefore
> a lot of versions etc. It will only take one of those files to be out of
> step (on moving or re-installation) and the whole thing will come
> trashing
> down.
> My preferred approach would be to build an application comprising of
> just
> 2 things: a small workspace PLUS a database. Everything gets stored in
> the
> database, including custom (such as component files) & text files etc,
> workspace variables, functions etc. A database can store like named
> objects if the name of the object and one or more keys are used.
> At run time, the workspace extracts its requirements & reconstitutes
> itself (to any configuration)-on a needs basis.
> I have tested this approach with APL+Win and Oracle/SQL Server (I think
> DB2 & SQL Anywhere would be ok too): it works very well. With APLX, it
> works but not quite as well with files: I am still investigating.
> Do you know if a C# DLL compiled on Windows will run on Unix/Linux: I
> hear
> that Mono has come a long way. If it does, it would make everything so
> easy: APL will just have to call the DLL functionality that can take care
> of all the nasty bits.

And so you restrict yourself to the x86.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

J. Clarke

2006-02-08, 9:02 am

Mike Kent wrote:

> AA2e72E wrote:
>
>
> I think you mean "Dick Bowman's approach".
>
>
> ... a lot of registry keys,

One registry key and some quantity of subkeys.

>
> ... It will take only one of those registry keys to be out of step ...

Except that they're all in one place, and the operation of the registry
itself is not dependent on any of your keys being correct.

If you want to write for Unix write for Unix, if you want to write for
Windows write for Windows. If you want to pretend that Windows is Unix or
that Unix is Windows then please include a case of Scotch and a crate of
aspirin with every copy of your application that you ship.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

Mike Kent

2006-02-08, 9:02 am

J. Clarke wrote:
> And where would this "persistent store" be kept?

File-based config goes under /etc. The Windows XP equivalent seems to be
\WINDOWS\system32\drivers\etc.

> I'm sorry, but you're weaseling here.

I suppose that if by "weaseling" you mean "pointing out that there is no
essential difference between keeping configuration in a documented file
in a documented place, and keeping configuration under documented keys in
the Windows registry (except that the latter will work only on Windows
systems)" (because both the file system and the registry are just particular
implementations of a tree with named nodes and persistent storage at the
root nodes), then I'm weaseling. I /thought/ I was making a point.

Mike Kent

2006-02-08, 9:02 am

J. Clarke wrote:
> Mike Kent wrote:

>
>
> Except that they're all in one place, and the operation of the registry
> itself is not dependent on any of your keys being correct.

??? The operation of the file system is somehow dependent on a file
(oar a record) being somehow "correct"? I seem to be missing something
here.

> If you want to write for Unix write for Unix, if you want to write for
> Windows write for Windows.

I work where the work is, and at the moment that's Unix. It has been
Windows, and it was for a time VM/CMS.

> If you want to pretend that Windows is Unix or that Unix is Windows

I just want to pretend that Windows and Unix both support a file
system ... but wait ... they /do/ both support a file system, I don't
have to pretend.

> then please include a case of Scotch and a crate of
> aspirin with every copy of your application that you ship.

If you can make file-based configuration work reliably on any of Unix,
Windows, or a Mac, or a mainframe, you can make it work reliably on
any of the others (OK, maybe it's a bit more effort MVS/TSO). At one
level the APL code to do it should be invariant; at another, it is
native-file utilities you have lying about anyway (which do vary in
implementation from platform to platform, but they present a uniform
interface -- don't they?).

J. Clarke

2006-02-08, 6:56 pm

Mike Kent wrote:

> J. Clarke wrote:
>
>
> ??? The operation of the file system is somehow dependent on a file
> (oar a record) being somehow "correct"? I seem to be missing something
> here.

The operation of whatever you're using to keep your information organized,
if it is contained in a bunch of interlinked files, depends on those links
being correct.

If it's just a flat file then storing the information in the registry would
seem to present no more problems than putting it anywhere else.

The registry has its own manager, its own structure, its own security.

>
> I work where the work is, and at the moment that's Unix. It has been
> Windows, and it was for a time VM/CMS.

Which has absolutely nothing to do with anything that I said.

>
> I just want to pretend that Windows and Unix both support a file
> system ... but wait ... they /do/ both support a file system, I don't
> have to pretend.

Yes, they both support a file system. So what?

>
> If you can make file-based configuration work reliably on any of Unix,
> Windows, or a Mac, or a mainframe, you can make it work reliably on
> any of the others (OK, maybe it's a bit more effort MVS/TSO). At one
> level the APL code to do it should be invariant; at another, it is
> native-file utilities you have lying about anyway (which do vary in
> implementation from platform to platform, but they present a uniform
> interface -- don't they?).

Reliability is not the issue. You can do things in very, very weird ways
and still have them be reliable. The problem is that when they break, the
farther from accepted standards they go the harder they are to
troubleshoot, and the more reliable they are the worse it gets--if
something crashes every day you learn where all of the relevant
configuration information is located, if it crashes once a year then you
have to look it all up every time.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

J. Clarke

2006-02-08, 6:56 pm

Mike Kent wrote:

> J. Clarke wrote:
>
> File-based config goes under /etc. The Windows XP equivalent seems to be
> \WINDOWS\system32\drivers\etc.

I see. So what do you do when the "WINDOWS" directory is not "WINDOWS" but
"WINNT", which was the default for some versions? Or if for whatever
reason the administrator has decided to use some other name for it?

And how do you handle user-specific configuration? Do you run a privileged
process just to handle it or do you require that all users be granted
privileged access to a system directory or what?

What you're describing is something that Windows application programmers
used to get away with. With Microsoft tightening the default security
levels and with administrators learning to tighten them even farther that
approach doesn't fly anymore.

>
> I suppose that if by "weaseling" you mean "pointing out that there is no
> essential difference between keeping configuration in a documented file
> in a documented place, and keeping configuration under documented keys in
> the Windows registry (except that the latter will work only on Windows
> systems)" (because both the file system and the registry are just
> particular implementations of a tree with named nodes and persistent
> storage at the
> root nodes), then I'm weaseling. I /thought/ I was making a point.

By "weaseling' I mean that you were spouting a lot of bullshit instead of
answering the question.

As for "the latter will work only on Windows systems", putting stuff in /etc
won't work on Windows systems unless the administrator has chosen to give
you the privilege of creating folders in the root directory of the boot
drive, so it's no more portable than the other.

--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

Sponsored Links