The object storage (Editorial)

OK, This project is taking alot of time on just the object storage. Why not just make a plain file system (folder+file) and get Screens out the door? This is a constant question I have got and the problem is that people dont understand why this single component is the most important in this project. Data - Its all about Data. Computers manipulate data thats all. You have different storages like RAM, Hard drive, Disk-On keys, SD Cards which hold data. The computer or device manipulates that data either by reading or writing to it. A computer is useless without memory because you couldnt do anything with it. So data is important but whats wrong with a file system? Lets go through the changes that Screens object storage improves over a normal file system: 1. A folder can be a file and visa versa In current file systems, you have folders and files where folders provide structure and files provide data. In Screens, an object is both a folder and file, so it can hold both structure and data. How does this help? Well... its like bundling. You can move an application (data) to another device and it includes all the structure and data of the application with it. It gives more flexability and makes information more accessible. 2. Links are direct manipulation Unlike shortcuts which are basicly files that direct you to the real file/folder, links act exactly like the object it points to apart from moving, removing or copying the link which just copies the link, not the object it points to. But anything else affects the link directly. This means that you can use a link anywhere you would put an object the difference is that links point to the object, its not the object itself. Using links you can make the tree structure of objects more flexible. 3. Links are like aliases and hard-links Links point to objects by thier handles so it does not matter where the object is moved to, the link stays pointing to the correct location always untill the target object is removed in which the link is removed as well. 4. Data of objects can be shared over multiple objects with different access policies. Instead of an object exclusively owning the data, it can be shared over multiple objects so each object feels that it owns the data and can manipulate it but the data is only removed when no objects own the data anymore. However each object can have an access policy where it can be allowed to only read the data or have read and write abilities or it can be allowed to only write to a local copy which is called Copy & Write. Copy & Write means that you can read the shared data but if you write to it, it creates a copy of the data and writes to the copy. If the object is the only one who owns the data, it does not make a copy. 5. Object locking Threads can read data freely but only one thread can write to an objects data. All other threads are paused untill the exclusive hold of the thread on the objects data is released (which is when the thread closes the object data). A thread also has to wait untill all threads give up read access before it can get exclusive write access. This makes sure that no two threads will ever read and write at the same time which is a common problem in multi-threading environments. This means that developers dont need to deal with semaphores or mutexes, the system deals with this for the developer. 6. Objects have operations Each object can have operations called Methods. Method are ways to manipulate data using module code. For example an email has a method called Send which sends the email. A music object has a method Play to play the music in a multimedia application. 7. Objects have types Unlike extensions, Objects can be based on multiple types so an XML file can be based on the XML type which is based on the text type so any text application can open the XML file and also any XML application can open the XML objects. Types also allow to provide default properties for objects so for example the window title color can be made a default value in the window type and any window which does not provide a different title color will get the default window color. This is just a tip of the iceberg of what Screens object storage will able to do. It also deals with threads as batch jobs where only in specific locations do threads actually write the object storage which allows for application crashes not to leave objects in inconsistent states. It deals with versioning, extending types and object properties, members and data. Its very simple design allows to be flexible and powerful and still work on handheld devices like PalmOS and PocketPC devices.