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

[Johnny Billquist]

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

Because nothing is set in stone? People use the system, people change 
content, people transfer files, people do all kind of strange things...
Imagine...

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

So you have a sequential file with variable size records, and no file 
attributes. How do you find the size?

	Johnny