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

[VAXman- at SendSpamHere.ORG]

In article <nkhf0u$71o$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>On 2016-06-23 21:42, VAXman- at SendSpamHere.ORG wrote:
>> 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.
>
>Assuming you then keep track of this converted file, it does not change, 
>and you have the storage, yes...

Why would it change?



>>> 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.
>
>Whoa! I don't know about you, but personally I would be extremely pissed 
>if a tool that is supposed to only read my file were to modify it. Even 
>if the contents supposedly should appear to look the same afterwards.
>
>But you're even making some pretty horrible assumptions here. Assuming 
>that the file even is a text file to start with, for which conversion to 
>a stream, might be assuming too much.

If it's not text, then what does it matter?  Binary?

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

I speak to machines with the voice of humanity.