|
Ok, today we have shells like bash that can help you navigate around a file system, find files, run files, search files, view files etc. Common tools are grep, less, cat, "|", awk, sed, perl, tr, wc, find, etc. The <cr> is a poor mans record seperator. Experienced people can often do non-trivial things in shell by combining a tools, regular expressions, and manually filtering out false positives. I.e. using grep foo | grep bar for that one email you are looking for. But as a result things that need more structure require significant coding and create a sandbox that doesn't work well with other systems. Like say thunderbird (an email client). Now imagine something different that has some higher level of abstraction. Maybe every file gets by default a list of functions to help the OS understand it. How about dump (raw byte encoding), list, add, view, delete, and search. Each file type supported by the OS would get those features, one of those might be jpeg. So of you created an address book, you'd define a record type called person, and a list of fields. One of those fields might even be a JPEG for a image of the person. In a GUI (like thunderbird) you'd just wrap a function called addressbook.insert much like just about every GUI platform has a file picker. Ideally every application on this OS would make use of these function calls so every app that needed an addressbook could share the OS calls to interact with the addressbook. But also instead of being frustrated at thunderbird you could use your addressbook for new and different things. Like say a map viewer might put icons up for every home address in your addressbook. Or you could query you addressbook for the home address nearest you... from the command line. Ideally this files are actually objects that include data and code. Said code could inherit based on primitives from the OS like records and fields. That would enable things like extending the addressbook to handle a new field like your keybase ID, PGP key, 3D representation of your face or whatever. Similarly any image viewer, or even a pipeline using standard image tools could iterate over all your JPEGs and extract geo tags. The object aware "find" replacement could access records/fields for all file types so you could find photos within a distance of a long/lat. By combining the above with a relational database instead of a filesystem you could mix and match and create virtual folders for things like the top 1000 newest images on your "filesystem". Suddenly replacements awk, sed, wc, less, etc would understand email message metadata. Or make a directory that contains the newest email messages you haven't replied to. Running ls --fields=From,To,Date,subject would give you a summary of email in a folder. The code replication for understanding a file format, serialization, communication, etc would be greatly reduced and moved largely from the application space to the OS space and result in significantly increased compatibility between applications. Imagine instead of a zillion files under ~/.thunderbird that instead it was all in a database compatible with any email client that's supporting the new record/field standard. |