Re: WHY doesn't C know anything about directories?

Mark McIntyre wrote:
On Thu, 07 Jun 2007 08:30:41 -0700, in comp.lang.c , David Mathog
<mathog@xxxxxxxxxxx> wrote:

It would be nice if the language supported
these machines.

No need, since platform-specific extensions do it very well.

There is a need because it's a PITA to port those platform specific
extensions to another set of platform specific extensions.


C. How many keys do these proposed database filing systems require?
The proposed navigation calls already support UP, ACROSS, and DOWN
navigation directions. That should be sufficient to navigate within
a database so long as a list of valid keys can be retrieved and
the number of keys needed to index a file location is finite

I don't think you understand how a database filesystem works. Consider
an ordinary RDBMS. A row isn't 'down' from a table, and a row in a
different table isn't 'across'. if you select * from table where
filetype=bla and filedescription like gibble you don't get some sort
of hierarchical tree returned.

UP ACROSS and DOWN define navigation on a grid on a 2D surface, which may or may not have a tree based file system mapped onto it. If a
database can be mapped so that every file it contains lies on
that 2D surface then UP ACROSS and DOWN should be sufficient to navigate to any of those files. (Not necessarily trivially to any SET of those
files, as could be done with SQL select statements.) Also the navigation path to each cell, and especially from cell to cell, may not be unique, but that's true now on Unix directory trees with links between directories in place.

Another way to think of it with respect to a database
method would be "Less Restrictive", "As Restrictive", "More Restrictive". Let's ignore the middle one for a minute and work the
example you cited. Admittedly it is a bit counter
intuitive if you're thinking in terms of SQL select statements.

In your example we need to get to all files "in":
some table, filetype=bla, filedescription=gibble.

Start at the database "TOP" (nothing selected)

Navigate DOWN: Lists all tables, from list select a table.
Navigate DOWN: List all columns in table, from list select "fileteype".
Navigate DOWN: List all values in column, from list select "bla".

(if we directory list at this point we get all files for which the database has filetype=bla.)

The next step is where it becomes counter intuitive. To further
restrict the specification ("DOWN") after one column has been
set requires selecting another column and a key value in it, like this:

Navigate DOWN: List all Columns in table ([OTHER than the one(s)
already selected] ie, further restrict list),
from list select "filedescription".
Navigate DOWN: List all values in column, from list select a
value like "gibble".

List directory: all files for filetype=bla, filedescription=gibble.

UP is even less familiar since it is multivalued.

Navigate UP: lists all less restricted paths, which in this case are:
1. column=filetype(value=bla),column=filedescription
2. column=filetype,column=filedescription(value=gibble)

Admittedly this is all AND logic, but it should be sufficient to
find any file stored in the database system, or to place a new
file in the system. It cannot do SETS of files with as much
flexibility as a SQL select statement, but then, none of the native directory tools I'm aware of are designed for operating on sets of directories.

The biggest problem I see is that if files in a column were ONLY organized by numeric indices (for instance a collection number) the list that came back would be both humongous and essentially meaningless, so
that selecting the next value would be next to impossible. This is exactly analogous though to creating a zillion subdirectories
with equally meaningless names. Unfortunately an organization
I've encountered a few times.

My point still being, that with C modified this way the program
just sees standard function calls for navigating UP and DOWN and
lists of results, and C never exposes the underlying database or directory organization. This would allow the same program to
run unchanged on an OS with a tree file system or a database
file system. That would, I think, be a good thing.

Regards,

David Mathog
.

Relevant Pages