Re: More spfile goodness
- From: "Nuno Souto" <dbvision@xxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 7 May 2004 20:31:46 +1000
----- Original Message -----
From: "DENNIS WILLIAMS" <DWILLIAMS@xxxxxxxxxxxxx>
> 1. One of the purposes of the SPFILE was to be able to have the same
> SPFILE on every server, to support the surge toward grid computing. I
think
> that is why they didn't move some of these parameters to the control file.
Sure. I just don't see in what way, shape or format does that necessitate a
binary paameter file? And quite frankly: parameters that may be necessary
for the proper operation of a multi-node engine are best kept in the
classic control file.
There is no reason why multiple control files can't be maintained across
nodes
anymore or any less than a binary SPFILE, a text XML file or a simple
init.ora.
> 2. Microsoft seems to be moving away from simple, editable files toward
> files that have a GUI interface.
Again: that does not in any way preclude the use of text (or XML) for data.
How it is shown to or manipulated by the user has got nothing to do with
how it is stored. If we go that way, then pretty soon we won't be able to
store data in a RDBMS "because the front end" has changed?
> And often Oracle is forced to appear as
> "user friendly" as MS.
Absolutely. The relevance of that to file formats is?
> If you've ever designed an interface for many
> customer sites to use, you tend to get a little paranoid.
Sure. Apply security. Not obfuscation.
> Inevitably some
> person somewhere will scramble the plain text file beyond what you
> anticipated and then you the developer are tagged with having caused a
> "bug". Having a file the strange people can't legitimately edit (although
> some clever people on this list have done just that) makes the developer
> feel a little more comfortable.
Well here is a sequence a dumb user is 100 times more likely to perform
with a GUI tool, now that we have this "secure", obfuscated, "easy to use"
binary file:
1- jump to explorer.
2- drag the binary file and drop it in the bin.
Simple. Efficient. Zero learning curve. And it can even have special
effects with it, the multimedia bits ARE important!
Yet, I still see no compelling reason whatsoever to
"change-a-text-file-to-a-binary-file-and-keep-the-text-file"
and how it could possibly stop the above from happening.
Narh: the whole thing was half-thought and security was never a reason
for the change in the first place.
> Sorry if I've spoiled anyone's rant, it is just my nature to seek to
> understand the reasons behind the actions of others.
Mine too. And unless we're talking about a duh-veloper, I can't for the
life of me fathom why anyone would bother turning a simple text file into
two: one text, the other binary. Not in this day and age.
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxxxxx
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
