.But anyway, in its nature of being highly experimental, I'm going to scrap the traditional hierarchial method of storage and implement what I call an object-oriented method. It's still hierarchial, but it resembles classes in an OOP language than simply a filing cabinet. I'm not going to preach that it is so much better and that it's revolutionary, because in the end, you still have to have something to locate your data and both systems do the same thing. It's just that my system is organized a little differently. A lot of it is just the way objects (what replaces files) hold meta information. Also, objects can hold other objects, so basically an object serves the purpose of a file and a directory at the same time.
Objects are derived from templates. All templates are registered with the OS and once registered can be derived from at will. If I created a template for MP3's, I would derive a MP3 from it "dr #MP3 myMP3". Now if I wanted the title of the MP3, I could use "fopen("myMP3:title", "r")" and the object returned would operate just like a file would, but it'll only contain the title of the MP3 file. What fopen really did was send a request to the template of MP3 and depending on how the author coded the template (probably in C++) it would return a value. In this case, the code will search for the title in the ID3 tags and return it.
What happens if I do this: "fopen("myMP3", "r")"? It depends on the code of the template. In this case you would be returned the MP3 in the same way you would in a traditional OS. This is the default action. Templates can derive from other templates as well. For example, maybe somebody creates a "MP3_Play" template that allows you to access a method. Instead of working on a bunch of code for playing the audio, you can derive from the "WAV_Play" template. Now you have the method for playing audio defined for you. All you have to do is stream the uncompressed data to the play method. Yes, objects can have methods, and they can be opened like files too.
To operate with an object's method, you use fopen as well. If "myMP3" has been deleted and a new objected is derived from "MP3_Play" to take its place, we could do this: "fopen("myMP3:play", "w")". To operate with this function, you simply write to it. This is kind of like the way devices work in *nix. When you derive a template from another template, the functions of the parent template are located like so: "MP3_Play\WAV_Play:some_field_name_here". So the MP3_Play:play method's job is to stream uncompressed WAV data to "\WAV_Play:play". The author of MP3_Play was pretty lazy, so he made to where you can either make the MP3 start or stop playing from the beginning. I would just have to write a "1" to it and it'll start playing. If I write a 0 to it, it'll stop playing. Writing data to the open method will run the method and it'll take the data you wrote to it as a parameter.
Basically, you could operate a great deal of your computer from the command line without having to run a single program. You can play MP3's simply by writing a "1" to a MP3_Play object, or extract its ID3 tags. You can extract a file from a GZ_Archive object by writing "x:myfile" to the GZ_Archive:extract method. Basically, you still have to have code for functionality, but programs are hidden and instead you access the objects and they handle the tasks transparently.
Since writing data to methods is so common, a shorthand is going to be implemented in my shell. If I had a GZ_Archive open called "foo" I would do this: "foo:extract("x:bar")" to extract the file "bar" from foo. The GZ_Archive template determines what type of object "bar" is a retrieves an appropriate object. In this case, there is no templates that match bar, so it returns a "File" object, which is a wrapper for files from other OS's of an unknown type. It basically just contains the file as-is in the "File:data" field, and it uses the default action, so if you did this: "fopen("my_file", "rw")" it would give you the data of the file just like the default action example above.
I'm planning on implementing the networking stuff this way too. I'm going to have a network sysobject (A sysobject is a singleton object the the OS itself creates) and you can derive a data transfer object, fill it up with data you wish to send, and then move it to the network sysobject's queue. The network sysobject will send all the data transfers in queue automatically, so you don't even have to worry about the data afterwards (such as when you try to send a large string over the network and not all it gets sent and you have to keep using send until it all gets there). Granted, there will be times where you'll need to get more low-level, and the network sysobject will provide that functionality as well.
My standard library might just be a bunch of functions rolled into headers that call fopen's on sysobjects. Of course, for some things this is unreasonable and it's better just to have plain C code. For many things though, this is a good way (at least I think so) to get things done. It's just going to take a LONG time and a LOT of code to get me there. I'm in no rush, I'm doing this purely for my own entertainment.
