LarchFSIdea

So, here's an idea. We want some way to query specific attributes of meta-data from an object as well as the get the whole-blob as well as get just parts of the data out of the blob.

We have discussed making a LarchDataDescription that would allow one to query the file for specific attributes. We had been thinking then of having a client-library for NameYourLanguage or NameYourApplication that would be able to use the LarchDataDescription and the blob to implement queries on the blob.

Here's a different thought altogether. What if we made a file-system where each blob had several entries in the file-system:

• the blob itself
• the LarchDataDescription of the blob
• the canonical keywords
• specific entries based on the type of data, maybe:
  • the raster data
  • the n-th slice of raster data
  • ...

The advantage is that if you implement the file-system for the OS, then you've automatically have access to it in every programming language and every application.

The disadvantage is how do you represent the keywords. Suppose the blob is /foo. You might like: /foo/keywords to be a big "file" detailing all of the keyword/value pairs. But, then when someone goes to read /foo/keywords you have to dig out all of the possible keywords out of the blob (or you have to have done this previously).

So, instead, you might like /foo/keywords/width to be a "file" containing only the width of the raster data. But, then you have the overhead of open, read, close for every keyword you are interested in... although you can have keywords of arbitrary format this way.

Another disadvantage would be... so you've got a raster. Rather than scanning left-right-top-bottom (LRTB) like most rasters, this is a Windows BMP... so it scans LRBT instead (WhyBMPsScanLRBT). Should the filesystem support both /foo/raster/lrtb and /foo/raster/lrbt? Of course, this problem occurs just in the LarchDataDescription arena, too. Are we canonicalizing all rasters to scan the same way? all pixels to interleave the same way? if not, do we really expect all apps to know what do when they get Bayer-ed data [LarchHurdleWeirdData]?

-- PatrickStein - 31 Mar 2005

Some of these concepts have already been hashed out a bit in the LibFerrisProject. But, that project is a user-level FS interface, not an OS-level.

-- PatrickStein - 04 Apr 2005