[Info-vax] callable BACKUP example

[Dave Froble]

On 7/15/2021 8:25 PM, Stephen Hoffman wrote:
> On 2021-07-14 22:57:20 +0000, Dave Froble said:
>
>> On 7/14/2021 12:31 PM, jimc... at gmail.com wrote:
>>> On Thursday, July 8, 2021 at 5:47:45 PM UTC-7, Dave Froble wrote:
>>>
>>>> "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: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486