This almost belongs in a category with the CP or Configuration Partition but this deserves its own place. Essentially it will be on its own but it'll be a very big part of the CP.
The file types table will almost be it's own database. It'll be a series of tables that are each defined by the type and will most likely hold the meta-data for the specific type in question. Generally meta data for a Word document shouldn't change for each Word document, so keeping the meta data here makes sense. The information stored will be information that is used in the database but it will also store the filename. This is key in the duplication process because if you have 2 files with the same name and type, chances are they're the same file. If they're the same file it makes no sense to have multiple versions. Versioning will be possible but that will be covered later.
Here's a couple of points:
- Application developers will develop their own type “table“ and link the relations
- Changing a file type means deleting from table x and inserting into table y. Nothing else changes but the meta-data might. If the meta-data is the same (i.e. name column is in both tables) then the information will be retained. Any information not found in both tables will be discarded.
- On-line registry of file types and their functions directly from the makers of the OS. Developers will sign up for specific types and will be locked in so to speak to make sure people can't just make up their own types and/or replace others.
Unlike DOS and Windows, file types (extensions as they're called) will not be subject to just 3 characters. Most likely if I can code it, they'll be permitted to use 128 characters which is a lot more than 3.
File types can be downloaded from the internet along with the meta-data so that if you ever download a new file, the database can accommodate as necessary. As more types are registered, updates will be made to the system so that they become widely used and accepted. They'll be extremely easy to implement so that you can provide temporary fixes as needed but once an update is made it will lock the type so that no one outside of the original developer can make changes to the table. This is to keep the meta-data uniform and neat.
This shouldn't be difficult to implement but it'll be a challenge to figure out how the database portion of the file system will be carried out. I think file types is the best way to categorize data into tables but it'll be difficult to use at first. Since initially no file types will be taken, there'll be a lot of room for error and growth. If there are disputes between types I'll most likely make the final judgment calls based on polls or other devices on a website. I want this to be a community effort where a developer can extend the capabilities of existing technologies while have the ability to construct their own with very little intervention.