[Info-vax] RMS record metadata, was: Re: Re; Spiralog, RMS Journaling (was

[lawrencedo99 at gmail.com]

On Wednesday, June 22, 2016 at 1:53:59 AM UTC+12, Bob Koehler wrote:
> In article <877c262a-6c6e-45f6-ad86-e884ffda2212 at googlegroups.com>,
> Lawrence D’Oliveiro writes:
>> On Sunday, June 19, 2016 at 6:41:48 AM UTC+12, Simon Clubley wrote:
>> 
>>> Also, IMHO I think the default sequential record type for today's
>>> world should be stream (and hence the terminator is also included in
>>> the file data.) I do not think it should be variable length records.
>> 
>> Hands up all those who think RMS should die already...
> 
>    Them's fight'n words.

RMS does too many different things, all tied together:

* I/O buffering, because the underlying ACP/XQP layer only allows reading and writing whole multiples of 512 bytes (how dumb is that?).
* Enforcing a bunch of pointless record formats, kind of tied in with the buffering issue, but really just to prevent you from reading and writing files as streams of bytes.
* Implementing an elaborate ISAM file format. This might be useful, until you consider that something like SQLite offers far more functionality, at a low enough overhead to be included as standard on that Android phone in your pocket.
* Filespec parsing (nothing to do with the “R” in “RMS”!). I remember looking at the microfiche source for this in days gone by, to see notes about bugfix after bugfix in the header comments. Why was this ever written in assembly language? Was it ever rewritten in BLISS?

Of these, none is worth keeping. Except maybe that last one.