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

[Johnny Billquist]

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.

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...

	Johnny