Half-baked idea alert!
So, I’ve always been rather annoyed with file I/O. Many’s the time I’ve wished for an extendable file manipulation framework with which one could specify any file format, and have it be properly parsed into a nice structure.
I was just reading a webpage which referred to UNIX’s “everything’s a file” philosophy as “everything’s an untyped bytestream.” And it occurred to me — why the hell don’t filesystems have type support?
I mean, yes, you need to be able to convert to untyped bytestreams to communicate with the rest of the world. But having actual semantics in your filesystem would be a *huge* win. “Everything’s a typed data structure.”
How about it, science?
Anonymous said:
Jun 09, 04 at 1:21 amSee: CTO:File System; CTO:Orthogonal Persistence
Jeremy said:
Jun 09, 04 at 3:35 pmWho are you, masked stranger?
My thoughts on this are mostly pragmatic. The lowest common denominator is going to be a stream of bytes. There’s no getting around that; it’s the hole we’ve dug ourselves into. (This is why resource forks disappeared from Macs.) Being able to access that representation is important; there’s no use in constructing a system which can’t communicate
to the outside world. It’s being restricted to that bytestream representation that is the problem.
I guess what interests me is the layer which converts a bytestream representation to a structured, typed representation and back again, somewhere where it can be endlessly reused and built upon. Some sort of OS-level framework which eliminates the headache with bootstrapping data. Whether this is done with orthoganal persistence or not isn’t really the issue in my mind right now, although it certainly has a mindset which would make such things much simpler.
Think UNIX pipes with structured types, I guess.
“cat bla.jpg.gz | gunzip | jpg2jpgstruct | jpgstruct2imgstruct | imgstructdisplay”, or
“cat foo.c | c2cparsetree | cparsetree2ir | optimizeir | ir2executable > foo.exe”.
Filters stacked one on top of another.
I certainly see your point, though.