4 ms·

“I know I saw a spreadsheet a couple of weeks ago; when I want to find it again do I look in my file system or do I look in my email?”. Bill was trying to make

by andor 13y ago

“I know I saw a spreadsheet a couple of weeks ago; when I want to find it again do I look in my file system or do I look in my email?”. Bill was trying to make multiple points with this simple example, but the primary one was not that there should be a way to search across disparate stores. (from part 1 of the series) My first thought was: put your mail in a Maildir instead of that pst file and you have "unified" storage ;-) It seems they wanted to build something like the opposite of Unix: "everything is a (structured) database" instead of "everything is a file".

viraptor 13y ago
Why would Maildir help here? Unless the file itself was saved separately and linked from the email in an app-specific way you still wouldn't be able to open it directly in your spreadsheet app. (excluding fusefs-style magic) Unless you have a well-defined structures stored somewhere, you just get extensions on top of extensions... see things as simple as 'ar' files for example. Also Maildirs have lots of different formats and ways of indexing - each app treating the files as "just files" and doing it in a very specific way :( Sometimes I really appreciate the "here's an API, you will never know where/how it's stored and you shouldn't care" approach.
- andor 13y ago
  Unless the file itself was saved separately and linked from the email in an app-specific way you still wouldn't be able to open it directly in your spreadsheet app. That's true. You might be able to find the right mail file using text-based tools, if the mail isn't MIME encoded, but then you still don't have the file. I just found it fun to think of it as the opposite of Unix. The Nepomuk framework in KDE seems to have similar goals by the way. They kept their database separate from the filesystem, but integrated it in quite a few KDE applications. Nepomuk uses a graph database, so the schema is easily extendable. But apparently they don't even use all features of the current schema, only rating, tagging and comments appear to be consistently implemented in applications. http://userbase.kde.org/Nepomuk http://userbase.kde.org/Nepomuk

by andor 13y ago

viraptor 13y ago

Why would Maildir help here? Unless the file itself was saved separately and linked from the email in an app-specific way you still wouldn't be able to open it directly in your spreadsheet app. (excluding fusefs-style magic) Unless you have a well-defined structures stored somewhere, you just get extensions on top of extensions... see things as simple as 'ar' files for example. Also Maildirs have lots of different formats and ways of indexing - each app treating the files as "just files" and doing it in a very specific way :( Sometimes I really appreciate the "here's an API, you will never know where/how it's stored and you shouldn't care" approach.

andor 13y ago
Unless the file itself was saved separately and linked from the email in an app-specific way you still wouldn't be able to open it directly in your spreadsheet app. That's true. You might be able to find the right mail file using text-based tools, if the mail isn't MIME encoded, but then you still don't have the file. I just found it fun to think of it as the opposite of Unix. The Nepomuk framework in KDE seems to have similar goals by the way. They kept their database separate from the filesystem, but integrated it in quite a few KDE applications. Nepomuk uses a graph database, so the schema is easily extendable. But apparently they don't even use all features of the current schema, only rating, tagging and comments appear to be consistently implemented in applications. http://userbase.kde.org/Nepomuk http://userbase.kde.org/Nepomuk