|Welcome to the ScriptOE!|
Draft 1 written by arschlesinger on 08, July, 2003
Draft NotesAs I, arschlesinger, write this draft, the ScriptOE is 'advancing on all fronts.' The core functionality(baseEnvironment.py) is growing to more than one file, and over 150 lines of code, and the website is changing by the minute. This may not sound like much, but the ScriptOE still is not nearly complete and is missing many features, which will eventually make the ScriptOE worthy of and easy enough to use for any user. The ScriptOE's growth, which has occured in less than a month, has prompted this draft, which aims to explain what the ScriptOE intends to do.
-->Please note that this draft will be changing in the future, and when it does, the changes will overwrite parts.
-->This draft should include numbered features, so that they can be referenced in the code
General aim: The ScriptOE's primary concern is to provide an environment for users that is easy to use.
The ScriptOE should work along- side the interpreters by identifying a script type, and then running the appropriate interpreter.
Eventually, however, instead of having to install the Perl interpreter on the user's system, one should just be able to use the ScriptOE to run a Perl script. A user who has never heard of Perl should be able to run a Perl script as easily as they can run a compiled program on their system. This means that eventually, the Python scripts that make up the ScriptOE will need to be compiled in some way.
To be consistent with the ScriptOE's general aim (stated above,) the ScriptOE should never get in the way of the user. By this I mean that if a user deletes a ScriptOE config file, the file should be regenerated, and the user informed that the file was deleted. Also, if a script is deleted or moved, then the ScriptOE should know, and tell the user. This means that the ScriptOE must have a way to track/install scripts.
The ScriptOE should store information in the XML format. In using XML, interested users can read and understand these files with ease. Also, every XML configuration file should be configurable with a ScriptOE interface, as well as manually. In allowing for 'front and back door configuration,' the ScriptOE configuration can be as easy and convenient for any user as possible.
As much of the ScriptOE's functionality as possible should be accessible from as many interfaces as possible. This means that a modularity system may need to be implemented soon. The ScriptOE could manage its own Python scripts in the same manner that it manages third-party scripts. With this functionality, a GUI version could exist, as well as a console version, as well as even a web interface(similar to Mozilla's XPI installation or the Click 'n Run system in the LindowsOS.) This functionality should not be a high priority. Code should be created, and then made as accessible and modular as possible.