|
Pages: [1]
|
 |
|
Author
|
Topic: REBOL File system? (Read 220 times)
|
|
GregS
|
Including binary within REBOL scripts need not require translation to base16 or base64.
The problem is solved by pre-scanning the binary and allowing for repeated markers.
In LAU the problem is handled in this way. A symbol "=" is scanned for in the binary, the maximum number of continuous occurrence are recorded ie "=======" then one extra is added ie "========" which is used as a proscript and as trailer to the bracketing of the actual code.
Hence "64#{UkVCT0wgUm9###ja3Mh}" might become "rawbinary#{####{UkVCT0wgUm9###ja3Mh}####}"
"####{" and "####}" acting as unambiguous markers for the included binary. There are other variations that may be far more REBOL friendly, once scanned the proscript marker could be anything, so long as it was repeated for the trailer.
Interestingly the same method could be used by amending XML to include a similar system (I have written to W3.org on this but that may well have been lost kin the system, I never got a reply).
In terms of filesystem binary files could, or any form of file, by saving to disk as amended XML or REBOL headed files.
The header area of REBOL files (or their XML equivalents) could also hold User associated information, system generated information, along with author's information in a safe way.
Eg "REBOL [author [.....] user [....] system [....] ]"
But why bother?
We have rapidly reached a point where data overload is a serious problem. Even our laptops have gigabytes of storage, the limits of named locations has become overburdened with the sheer amount of data being kept. In short unless we assume all computer users are anally retentive and religiously save files into a preordered hierarchy of locational directories, material is constantly being lost.
The first step in resolving this is to ensure all files are capable at least of being saved with useful descriptions of contents. The base line of this is to have a wrapper file format that allows all files to be described in a freeform way.
I believe REBOL application environment already has much of this first step in place. A few minor changes for REBOL 3.0 opens up great possibilities.
I would suggest one other change, REBOL wrappers that contain references to external files (that is external to the REBOL Application Environment). Wrappers which can be treated as if the file was included when it can be located and returns a specific error when it cannot.
|
|
|
|
|
Logged
|
|
|
|
|
|
Pages: [1]
|
|
|
 |