Thanks for the links. I was wondering what their power source is, and the Wikipedia article has the answer. Apparently they're turning diesel fuel and a bit of wind into plant growth.
I do something similar to the maildir approach, converting e-mail (from mbox files from long ago and from collected Usenet messages too!) to individual text files. Each text file contains the raw message text, encoded attachments and all, so nothing is lost.
However, I'm using BeOS's BFS to store these files so they are a more quickly searchable than plain text files (subject, from, to, dates are all indexed by the OS). Plus I file them away in directories by category. I also wrote a conversion utility [MailboxFileToBeMail] for mbox and Usenet messages that automatically attaches attribute tags to the message files, and even does international character set conversion on the subject and other key text.
The UNIX choices in this area are by design, not by an accident of history, and the motivations behind those choices are as valid today as they were several decades ago.
Is that still true? Disk storage sizes and speed have increased tremendously since the 1970s. Maybe we can now afford the extra storage space and time for database-like features (attributes with an index and query system). Or even simple things like doubly-linked file system nodes where each file knows what directory it is in.
Admittedly BeOS's BFS is slower than other file systems, such as when deleting files with lots of indexed attributes (it has to remove entries from the indices as well as the usual file operations). But it sure is nice to use from the user point of view. For example a window (looks like a GUI directory display window with the usual file icons) showing the results of a query (such as all e-mail type files with a subject containing some pattern) updates in real time, as messages come in or are deleted or otherwise changed.
Now that drives are faster, and algorithms for storage have improved (journalling and wandering logs), maybe it's time to add a bit of functionality and make things easier for the user, and programmer.
Slashdot Mirror
Thanks for the links. I was wondering what their power source is, and the Wikipedia article has the answer. Apparently they're turning diesel fuel and a bit of wind into plant growth.
I do something similar to the maildir approach, converting e-mail (from mbox files from long ago and from collected Usenet messages too!) to individual text files. Each text file contains the raw message text, encoded attachments and all, so nothing is lost.
However, I'm using BeOS's BFS to store these files so they are a more quickly searchable than plain text files (subject, from, to, dates are all indexed by the OS). Plus I file them away in directories by category. I also wrote a conversion utility [MailboxFileToBeMail] for mbox and Usenet messages that automatically attaches attribute tags to the message files, and even does international character set conversion on the subject and other key text.
- Alex
The UNIX choices in this area are by design, not by an accident of history, and the motivations behind those choices are as valid today as they were several decades ago.
Is that still true? Disk storage sizes and speed have increased tremendously since the 1970s. Maybe we can now afford the extra storage space and time for database-like features (attributes with an index and query system). Or even simple things like doubly-linked file system nodes where each file knows what directory it is in.
Admittedly BeOS's BFS is slower than other file systems, such as when deleting files with lots of indexed attributes (it has to remove entries from the indices as well as the usual file operations). But it sure is nice to use from the user point of view. For example a window (looks like a GUI directory display window with the usual file icons) showing the results of a query (such as all e-mail type files with a subject containing some pattern) updates in real time, as messages come in or are deleted or otherwise changed.
Now that drives are faster, and algorithms for storage have improved (journalling and wandering logs), maybe it's time to add a bit of functionality and make things easier for the user, and programmer.
- Alex