[Info-vax] CRTL and RMS vs SSIO
Stephen Hoffman
seaohveh at hoffmanlabs.invalid
Mon Oct 11 15:05:46 EDT 2021
On 2021-10-11 18:25:19 +0000, Simon Clubley said:
> On 2021-10-09, Dave Froble <davef at tsoft-inc.com> wrote:
>> On 10/9/2021 4:55 PM, Stephen Hoffman wrote:
>>>
>>> And here I was trying to explicitly not slag on RMS and its
>>> capabilities, as that'd solely serve provoke a torrent of folks quite
>>> reasonably pointing out that RMS is perfect for {app}.
>>>
>
> Actually to those people I would say that RMS is pretty much perfect -
> for applications written in Macro-32 that require record-level access.
>
> The RMS APIs perfectly match the huge level of work required in writing
> a full application in Macro-32 (that would be far easily written in a
> higher-level language) and perfectly matches Macro-32's utter inability
> to provide any meaningful abstraction layers in Macro-32 source code
> when compared to abstractions available in those same higher-level
> languages.
I spend too much time poking around in those same structures from C or
C++ too, even given the keyword arguments present in the CRTL API.
Dynamically adapting to the key structures within an RMS indexed file,
for instance.
> The RMS APIs are what you would have designed in the 1970s. They are
> not what you would design in this century.
For what it does, RMS works. Works well, too. It's less than fun for
inexperienced or new users, or for work such as evolving existing
record structures and cross-app-version and rolling-upgrade
compatibility.
The provided abstractions and features are comparatively weak.
>> Which it is, for those apps that need and use it's capabilities. Well,
>> maybe not "perfect". There is that lack of definition of data fields
>> that is so lacking in RMS. What I believe you call "marshaling".
>
> I would not describe this as marshalling, as marshalling is the
> conversion of data from one format to another.
>
> In this case, you would want the fields to be directly accessible from
> source code via a field-level API instead of a record-level API (as RMS
> is).
Elsewhere, I'm working with stuff where you tell the run-time "go store
this" with wads of in-memory data (objects, etc), and it goes off and
stores it.
The calls serialize the data in various formats, and the app developer
doesn't need to know the details.
For larger wads of stored data or where, various databases will account
for the structures of the stored data and map the memory structures to
or from the persistent storage structures.
The apps don't need to change unrelated field-level references whenever
the underlying storage structures change, either due to changes to the
underlying storage, or changes to the app.
--
Pure Personal Opinion | HoffmanLabs LLC
More information about the Info-vax
mailing list