Messages in this thread | | | From | Michal Jaegermann <> | Subject | Re: File systems are semantically impoverished compared to database | Date | Sat, 26 Jun 1999 12:46:28 -0600 (MDT) |
| |
Nathan Hand wrote:
> On Fri, Jun 25, 1999 at 10:28:21PM -0400, Arvind Sankar wrote: > > On Fri, Jun 25, 1999 at 10:55:07AM -0400, Lou Grinzo wrote: > > > You can get the performance today by using directories, but that > > > destroys usability. Documents need to appear as files to the user, > > > > Why must they appear as files to the user? I don't see quite what is very wrong > > with having a complex document as a directory. > > Not only is there nothing wrong with this approach, but for people who > use LaTeX for largish documents this is the way it *has* been done for > a number of years. > > Typically you create a "document" as a directory. [ followed by a description how you deal in a sane matter with a big LaTeX document ] .... > And in all honesty, what is stopping an application from keeping their > document format as tar, and unpacking into /tmp when you start work on > a document, then retarring at the end. All the speed, very simple. >
Although I agree with what Nathan wrote in the longish part of his description I think that the last quoted paragraph is misguided. The speed of taring and untaring IS NOT an issue even on a slow machine. When you work on a complex document hours at the time and days, or even weeks or longer, total these few extra seconds here and there are really irrelevant.
Myself I use for a work on (La)TeX documents emacs with auc-tex macros (and I definitely DO NOT want LyX started when I click on a document icon :-) and this supports notion "the whole directory as one document" even to a greater degree. It knows, for example, what my "master document" is and if I start dvi creation process on any of .tex source files it will begin transparently with a master document anyway. There are also simple ways to control what is included or excluded on a particular run, but I digress.
The point is that I emphatically **do not** want to hunt for a temporary directory de-jour where things were unpacked if I wish to have a look at a particular component. I also want to be able, without an extra hassle, to substitute temporarily my pictures with stubs, filter some parts of my document through a Perl script, generate other parts automatically from a report generator of a database and some other from a gnuplot output driven by a Fortran program and thousand of other things which I even cannot think of today.
If you think that you can provide a packaged abstraction which can support all my conceivable and not-yet-invented needs than this is great but I have to see it before I will believe in that. But I think that this is a waste of time as such abstraction already exists and it is called a file system and you better spent your energy on thinking how to improve and possibly generalize it instead of subverting it.
If you feel that this is important you may program a GUI user space utility which will pack the whole bundle into a "net-transportable" form and unpack it transparently. No muss, no fuss but keep a format standard across various OSes and platforms.
For those who think that archiving does not matter and is just a form of ensuring that all components are kept together think for a second how much wailing and flamage such trivial packaging format like RPM caused on this, definitely "computer-savvy", forum. If you are one of those who still cannot recover from an "RPM shock" here is yet another rpm unbundler:
#!/usr/bin/perl -w use strict;
my ($buffer, $pos, $gzmagic); $gzmagic = "\037\213"; open OUT, "| gunzip" or die "cannot find gunzip; $!\n"; while(1) { exit 1 unless defined($pos = read STDIN, $buffer, 8192) and $pos > 0; next unless ($pos = index $buffer, $gzmagic) >= 0; print OUT substr $buffer, $pos; last; } print OUT <STDIN>; exit;
There! It takes an rpm archive on stdin and writes cpio stream on stdout. If you think that this is a good idea extend OUT pipe with '| cpio -imd' and you will get a set of files instead. And all this teeth gnashing and strong words over those few lines of code...
Michal michal@harddata.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |