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

[Johnny Billquist]

On 2016-06-23 21:16, VAXman- at SendSpamHere.ORG wrote:
> 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.

Well, you believe wrong. An ftp server certainly do not have to provide 
a directory in a specific format, but there is an RFC that does describe 
this. But you are not obliged to implement that RFC.
But if you do, then a number of additional tools can talk to your system.

	Johnny