Post by Dave FroblePost by ***@gmail.comPost by Dave Froble"Cut-n-Paste" usually means the user didn't bother to understand the
example/source. That isn't a good idea at any time. The doc examples
are to help one understand, not to be blindly copied.
Cutting-and-pasting code into an editor so you can build and
experiment is an important expedient even if you're going to rewrite
and integrate independently.
Only if you understand what you're using.
I'd like secure code. I'd like perfect code. I'd like folks that
understand all aspects of the code. Or every aspect of the enterprise
environment. All those are wonderful and desirable and all the rest. But
that isn't the world that most of us live in and operate in.
You trying to say the world is imperfect?
Cut-and-paste app development is how the world works now, and I'd wager
~everybody here has used existing copyright-appropriate source code
examples as a starting point.
There is no sense in re-inventing the wheel, but, one should be sure the
wheel they intend to use is actually round, right?
Nobody is an expert in all of the OpenVMS APIs, and some of the OpenVMS
APIs can diverge widely (SMG, ACME, OpenSSL, etc) from the more typical
API designs.
You do like to understate some issues, huh? Imagine, calling something
an IOSB when it's format is not the IOSB we all know and hate.
The OpenVMS API designs are also wildly different from APIs on other
platforms.
Not an issue for some of us.
There are cases where the error handling is a central part of the call,
and existing OpenVMS examples tend to fail here. This includes BACKUP,
SSL/TLS, and a number of other contexts.
Copying cookbook code is how the world works now, how ~all of us already
or will be operating, and particularly with the sorts of complex and
glue-code-focused API designs prevalent on OpenVMS.
I just cannot get too comfortable with that.
Template source code examples embedded directly in documentation are,
well, archaic. And in various cases, won't build, or will omit important
API details in the interest of brevity of documentation.
Gee, you must have been attempting to read the TCP/IP docs ...
:-)
I'd prefer better abstractions in general, and I'd prefer the source
code examples be prepared as cookbooks with robust error handling, to be
buildable and usable, and with a permissive copyright. Let the docs link
to the cookbook.
Sort of like the older VMS documentation?
I'll again dare y'all: I *DARE* you to write a client-server app using a
SSL/TLS connection with proper certificate verification on both ends of
the connection, including the ability to detect interception, using the
current TLSv1.3 and secure encryption and key exchange. I *DARE* you.
And this is just the tip of the difficulty. ACME is no great joy to use
for a password verification—what should be an easy case—as another
example. I won't dare y'all to write that, as you'll fail.
So what, you like to place your bets after the race is run, huh?
I looked at such, and quickly saw that it just wasn't gonna happen. So
I started placing custom checks on data. I can control that to some
extent. I cannot control the wildness of the web.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486