<story><title>Why Files Exist</title><url>http://blog.filepicker.io/post/26157006600/why-files-exist</url></story><parent_chain><item><author>thoughtsimple</author><text>I disagree that files are the only solution. Back in the 90&apos;s Apple had an OS that had fully interoperable data in applications and that OS didn&apos;t have a file system.&lt;p&gt;It was Newton-OS and it used something known as soups for persistent storage. Soups were discoverable databases that intelligently handled Flash cards insertion/ejection. The ability to handle Flash on removable media is still something that mobile OS&apos;s have trouble with to this day.&lt;p&gt;The OS could merge soups on different stores dynamically and detect if some data in a soup was currently in use on an ejected card and ask for the card back. This merging of soups on different storage devices is something I&apos;ve never seen duplicated in the subsequent 20 years.&lt;p&gt;Files are not the only way to achieve the requirements in the article. They are just the common solution.</text></item></parent_chain><comment><author>wrs</author><text>Hey, someone remembers! (I did the Newton object store.)&lt;p&gt;I spent years of my life trying to get rid of treating direct user access to the filesystem as a foundational UI metaphor, at both Apple and Microsoft. As I liked to say, why is the UI based on a filesystem debugger? (If you can see /dev or C:\windows\system32, then yeah, you&apos;re running a debugger.)&lt;p&gt;Many people who aren&apos;t programmers don&apos;t seem to get deep hierarchy (deep meaning &amp;#62; 2 levels). Searching works, tags kind of work, but few people really know how to set up and use a folder hierarchy.&lt;p&gt;The reason it works to let the app deal with navigation is that the app knows how to do type-specific, contextual navigation. People like concrete things (whereas programmers like abstract things—a constant struggle). If you&apos;re trying to find a song, you want to have a UI that knows about songs: they come in albums, the same song may be on multiple albums, they have artists and composers, etc. Any attempt to represent that in a filesystem hierarchy can be nothing but a compromise.&lt;p&gt;This has nothing to do with defining standard formats for exchanging units of data. Just how you find them once you&apos;ve stored them.</text></comment>
<story><title>Why Files Exist</title><url>http://blog.filepicker.io/post/26157006600/why-files-exist</url></story><parent_chain><item><author>thoughtsimple</author><text>I disagree that files are the only solution. Back in the 90&apos;s Apple had an OS that had fully interoperable data in applications and that OS didn&apos;t have a file system.&lt;p&gt;It was Newton-OS and it used something known as soups for persistent storage. Soups were discoverable databases that intelligently handled Flash cards insertion/ejection. The ability to handle Flash on removable media is still something that mobile OS&apos;s have trouble with to this day.&lt;p&gt;The OS could merge soups on different stores dynamically and detect if some data in a soup was currently in use on an ejected card and ask for the card back. This merging of soups on different storage devices is something I&apos;ve never seen duplicated in the subsequent 20 years.&lt;p&gt;Files are not the only way to achieve the requirements in the article. They are just the common solution.</text></item></parent_chain><comment><author>kabdib</author><text>We stored lots more than just &quot;notecard entries&quot; in the Newton object store. We had application packages (with demand paging of compressed code). We had &quot;large binary&quot; support, similarly demand-paged. And all of this stuff was hooked up to the garbage collector.&lt;p&gt;I don&apos;t know how well it would scale to a non-hand-held device, but it worked really well on the Newton.&lt;p&gt;Files are useful, but they are not necessary. We are used to them, but there can be better ways to do things.</text></comment>