[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)

[VAXman- at SendSpamHere.ORG]

In article <nkhb28$5la$3 at dont-email.me>, David Froble <davef at tsoft-inc.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <nkh313$ekh$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-23 18:06, VAXman- at SendSpamHere.ORG wrote:
>>>> In article <nkgspt$rm$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>> This whole thread came about because some people pointed out that exact
>>>>> file sizes, to the byte, sometimes were wanted. And then it's been a
>>>>> thread of "why?". And when I give an example of why, it becomes a thread
>>>>> of "why?".
>>>>>
>>>>> Yes, I know VMS couldn't care less. RSX also couldn't care less. Me,
>>>>> writing an http server (as well as an ftp server), do care. And doing
>>>>> these things, which many people consider to be pretty basic tools that
>>>>> all systems should have, is a pain because the file system do not have
>>>>> this information.
>>>>>
>>>>> Yes, there are solutions. They are costly. Could there possibly be a
>>>>> point in adding this information, if it can be done at a low cost?
>>>>>
>>>>> You are just putting your head in the sand and saying that since it's
>>>>> not there, we don't need it.
>>>> Why pay for it when you don't need it?  Pay for it when you do!
>>> Which, for a web server, is every time a document is requested, which 
>>> might mean a dozen requests for a single page. And that is just one 
>>> example. And for a 10M document, calculating the size every time is 
>>> pretty costly... Reading through 10M to find the size, and then read 
>>> through it again, to deliver it. Color me not-excited.
>> 
>> Again, that's not a VMS problem; it's your/the protocol.  Perhaps, instead
>> of about it complaining here, you should complain to the IETF. ;)
>
>Agreed.
>
>> VMS moved files over the network without having to know the precise number
>> of bytes it has to move before doing so, so there could and there should 
>> and there are alternative ways this can be accomplished without knowing a
>> count beforehand.
>
>What about a protocol that allows data to be sent without a byte count up front, 
>terminated by some termination flag, and then the byte count so the receiver can 
>check for a good transmission?  Should work.

There are myriad ways to do it.  However, most of the TCP/IP suite protocols
contain an 'S' for 'simple'.  I'd contend, in many cases, that 'stupid' could
supplant 'simple'. ;)  In a great many cases, it sheer sloth.  Take a look at
the GUI based FTP programs as an example.  These, primarily, assume that the
server is or will produce an *ixy directory listing.  Point one of these at a
VMS FTP server which DOES NOT have or was not configured to provide the *ixy
directory listing, and the GUI FTP has fits and pukes up hairballs.  Is that
wrong?  I don't believe the RFC specifies that the listing must be in an *ixy
format, so the answer is yes.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.