Sometimes people rant. It's what we do. And sometimes it's awesome! In this particular case, we're going to drill down to a great rant from a community member:
Coding Cat is also an Editor/Answerer in the Small Basic Forum.
Coding Cat's Bio: I have been working with the PC since its inception in the early 80's. I was a professional developer / programmer-analyst / software engineer -- choose your favorite title -- for twelve years. During that time I worked for a wide variety of companies, on wide variety of topics in a wide variety of languages. My focus was always on low level system and language design. During the industry flame out following the burst of the dot-com bubble, when innovation stalled and things were boring, I returned to school to earn a masters in computer science and began teaching. As it turns out, influencing the nerds of the future is just as entertaining as being one yourself.
Let's get to this great rant from our Guest Blogger, Coding Cat...
===================================================
A Sandbox file object - Small Basic - Safe file operations for Seamless Sharing
Small Basic needs a new file object. Not a replacement. File does a great job with… well… with files. No, what Small Basic needs is a special purpose file object. Something that won't be commented out of operation by the "publish" process. A file object that lets you save and load files to the user of a newly imported program, on any computer, without security fears. What Small Basic needs is a sandbox.
Jibba Jabba commented on the topic of "Seamless Sharing" in a recent blog post:
Turtle-Maze vs Hangman - A Case for Seamless Sharing![]( "This link is external to TechNet Wiki. It will open in a new window.")
He outlines the process where Small Basic comments out all "File" operations in published code, and he gives examples of the issues that this causes. The basic logic is sound. If you remove the possibility of reading and writing to files on a computer, you eliminate any mischief that those programs can cause. The issue is that this kind of brute force modification to code will often render the programs unusable, or even cause bugs and compile errors.
I encountered that last issue myself recently with the game I wrote: Meteor Shower (import code: RJP883-15). After I first published the code, I realized that a silly amount of code was being commented out, gutting the high score system. More code removed than anyone would ever bother re-enabling. I sighed and reworked the system and got it down to two comment lines, one for read and another for write. Very proud of myself I published the code, only to realize to my horror two days later that the new import code wouldn’t run. If you imported and ran the program you would get a compile error (variable not initialized). Without the read, a variables value was never set and Small Basic choked. I needed to go back and waste a line to set a variable to zero just before the read set it again simply to allow the code to compile (import code: RJP883-17).
Jibba Jabba proposed an interesting solution. Giving each of the file operations an "enable" parameter. When enable is set to true (by default), the operation would function as normal. If set to false, as would automatically happen when the program was published, the operation would still compile and execute as before, the file operations would simply not function. Reads would return nothing, not having opened any files, and writes would never attempt to save any information at all. The true benefit would be stability of imported code. Because no code is commented out, or removed from the published files there would be no chance for errors. Code would run as before, only minus this one functionality. And changing the false values back to true would be just as simple as the uncommenting that is currently in use.
A very slick idea.
I have a different suggestion though. My idea is the creation of a Sandbox object.
The Sandbox object would be a set of file commands that allow the saving and reading from a file in much the same way that the File object works. The big difference is the sandbox file itself. The Sandbox would only save to a single file. The sandbox file name would match the name of the executable: ProgramName.sbox. The location of the sandbox file would always be in the same folder as the executable (Program.Directory). The sandbox file would be size limited to something small, like 50k. The other file operations would pretend that the sandbox file didn't exist, preventing rename and other operations from turning the sandbox file into something dangerous. Because of its predictable size and location, the sandbox file would be available to the online interpreter.
Secure, flexible and filling the needs of 99% of file operations that Small Basic is called to perform. Most importantly it would completely and perfectly fulfill the "Seamless Sharing" concept that is such an important part of what makes Small Basic great.
Jibba Jabba commented on the topic of "Seamless Sharing" in a recent blog post:
Turtle-Maze vs Hangman - A Case for Seamless Sharing
He outlines the process where Small Basic comments out all "File" operations in published code, and he gives examples of the issues that this causes. The basic logic is sound. If you remove the possibility of reading and writing to files on a computer, you eliminate any mischief that those programs can cause. The issue is that this kind of brute force modification to code will often render the programs unusable, or even cause bugs and compile errors.
I encountered that last issue myself recently with the game I wrote: Meteor Shower (import code: RJP883-15). After I first published the code, I realized that a silly amount of code was being commented out, gutting the high score system. More code removed than anyone would ever bother re-enabling. I sighed and reworked the system and got it down to two comment lines, one for read and another for write. Very proud of myself I published the code, only to realize to my horror two days later that the new import code wouldn’t run. If you imported and ran the program you would get a compile error (variable not initialized). Without the read, a variables value was never set and Small Basic choked. I needed to go back and waste a line to set a variable to zero just before the read set it again simply to allow the code to compile (import code: RJP883-17).
Jibba Jabba proposed an interesting solution. Giving each of the file operations an "enable" parameter. When enable is set to true (by default), the operation would function as normal. If set to false, as would automatically happen when the program was published, the operation would still compile and execute as before, the file operations would simply not function. Reads would return nothing, not having opened any files, and writes would never attempt to save any information at all. The true benefit would be stability of imported code. Because no code is commented out, or removed from the published files there would be no chance for errors. Code would run as before, only minus this one functionality. And changing the false values back to true would be just as simple as the uncommenting that is currently in use.
A very slick idea.
I have a different suggestion though. My idea is the creation of a Sandbox object.
The Sandbox object would be a set of file commands that allow the saving and reading from a file in much the same way that the File object works. The big difference is the sandbox file itself. The Sandbox would only save to a single file. The sandbox file name would match the name of the executable: ProgramName.sbox. The location of the sandbox file would always be in the same folder as the executable (Program.Directory). The sandbox file would be size limited to something small, like 50k. The other file operations would pretend that the sandbox file didn't exist, preventing rename and other operations from turning the sandbox file into something dangerous. Because of its predictable size and location, the sandbox file would be available to the online interpreter.
Secure, flexible and filling the needs of 99% of file operations that Small Basic is called to perform. Most importantly it would completely and perfectly fulfill the "Seamless Sharing" concept that is such an important part of what makes Small Basic great.
===================================================
This is a well thought out solution! Thanks for sharing! Sharing is a very important scenario for Small Basic. We'll make sure this get looked at.
You can find this article on TechNet Wiki as well:
We'll maintain that one if any updates are needed.
Small and Basically yours,
- Ninja Ed