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

[VAXman- at SendSpamHere.ORG]

In article <nkhdao$2us$3 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-23 21:23, VAXman- at SendSpamHere.ORG wrote:
>> In article <nkhcik$1o0$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>> On 2016-06-23 20:46, David Froble wrote:
>>>> Johnny Billquist wrote:
>>>>> 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.
>>>>>
>>>>>     Johnny
>>>>>
>>>>
>>>> Why would you read through it twice?  With a few exceptions, read it
>>>> into memory, then transmit it.  Something you got to do anyway.  Perhaps
>>>> just re-ordering the task.
>>>>
>>>> Too big?  Got to ask, what's wrong with doing things in segments?  Maybe
>>>> not how the *ix world does things.  Who's to say they are always right?
>>>
>>> I think you missed the point. For a web server, you *have* to give the
>>> size before you start sending data. Doing it in segments then obviously
>>> is not the answer. Nor is reordering of anything. Size comes first, data
>>> comes after. Do I have to repeat it again?
>>>
>>> And blaming Unix isn't useful/meaningful either. The protocol is that
>>> way. Deal with it.
>>> And yes, it can be too big to just gob into memory, not to mention that
>>> gobbing many megs of memory for this is a pretty poor design.
>>
>> OK.  So your web server sits on VMS.  If the file is NOT RFM=STM, call the
>> callable CONV$ert routine and convert it to RFM=STM.  There, done once and
>> then no more!  Now, you can have your precious byte-counted file size from
>> <end_of_file_block-1>*512 + <end_of_file_byte>.  Both values easily gotten
>> and the math is simple enough that even Bernie *should* be able do it.
>
>Apart from the fact that it's reusable, what you just did was read the 
>file twice, to serve it.

OK.  But only done once.


>And now you are creating alternative files for requested files, and need 
>to keep track which ones you have created an alternative for, and 
>substitute one for the other for those cases. I can see how this can 
>become rather exciting over time...

Overwrite the existing.  It's text and VMS can read it because it'll see the
record format.  

And, again, if you want a *FILE SIZE* that'll satisfy your TCP/IP and *ixy
file systems, you're going to have to send the <CR>s and <LF>s.  Now, it's
possible that you could use the same <end_of_file_block-1>*512 + <end_of_
file_byte> computation, but you don't have anything that indicates a count
of records which you might need to use to add 2*record_count to account for
the *synthesized* <CR>s and <LF>s in your stream.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.