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

[VAXman- at SendSpamHere.ORG]

In article <nkhd0k$2us$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-23 20:50, David Froble wrote:
>> 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 plenty of ways to design protocols.
>Doing the size after the file will not allow you to have any 
>understanding of how much space should be reserved for the file, nor get 
>any idea of how far you are from completion.
>But that should not stop you.

So I can get a silly progression bar graphic or, like on linux, file transfer
time left is 8 mins... 7 mins.. 9 mins... ... 10 secs... 5 secs... 14 secs...
2 sec., nearly complete...  transfer complete.

Anyway, there are web servers for VMS and several other TCP/IP protocols for
VMS.  You may need to ask those who have successfully implemented those how to 
approach your issue if you don't want to use the RFM=STM approach.  I really
don't see why you think that's wrong.  *ix text files are streams with <CR>s
and <LF>s, and binary files are, IIRC, sent in multiples of a block of some
size (512).

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

I speak to machines with the voice of humanity.