[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