"Alexander G. M. Smith" wrote:
> [...]
> and other people also commented on liking just files and directories.
> I can see how the object system could be expressed as just files
> and directories:
>
> * Each object becomes a directory. The name is the object's name,
> probably use the Human readable one to make manual hacking easier.
>
> * An object inside another object becomes a subdirectory.
> [...]
You need directory hard links to map object graphs to tree-structured
filesystems.
If an object database is mapped to a filesystem this way, every object can be
reached by traversing the object graph using a root object and following each
path component.
> * Each attribute becomes a file in the object directory, name
> being the attribute name and contents being the value of the
> attribute. Still, you need an extra type encoding somewhere
> to say that the attribute is a string, or number, or link
> reference or other simple type. Encode the primitive type as
> the first byte in the contents if there's no better way.
>
I'd discourage encoding primitive types as members of objects. I'd encourage
encoding instances of primitive types but references as objects themselves.
This makes primitive types independent of having a containg object, it enables
primitive types to dynamically grow in size and change in type (to complex
objects).
This leaves objects to be one of following:
- a primitive type
- an array of references (just in case you need native arrays, you could also
implement them as set of name-reference-pairs with the array-index as name)
- a set of name-reference-pairs (which can be implemented as arrays of
references to name-references-pair-objects) (this set is known as an
complex-object)
All known database types like table-structured databases and tree-structured
databases (including filesystems) can be implemented using this
graph-structure. Note that while this is the contract|API, primitive type
instances references by only one complex object may be aggregated into an
internal object containing the instances of primitive types directly and all
references to complex objects. Likewise this can be done with complex objects
which are only referenced exactly one time, forming a large aggregated tree.
Those aggregated trees just have to be expanded if member objects are
referenced more than once. How much it's worth to aggregate to a given level
of aggregation may be determined by a heuristic (like "primitive objects by
default, complex objects if they are older than 1 month").
After ten years, I see some convergence of relational-databases, filesystems,
tree structured files (like xml, source-code) into object databases. This
would make the vision more realizable and true that graphs of small objects
should be stored as graphs of small objects, not as large, aggregated files
with it's deficiencies (like that those graphs have to be complete,
referencing objects stored in other files is difficult).
However, implementing such a fine-grained object-database in linux efficiently
could fail due to the user-mode|kernel-mode barrier. Needing one system call
to dereference an complex object member isn't efficient, is it? But maybe
programs for a trusted, secure and defined environment (e.g. java
applications) can still make efficient use of that feature when a JavaVM knows
all places in the current executing code where a reference to not-loaded
object is deferenced. This code shall be modified sp that it loads the
Java-object from the object-database if it is not available, and if it is
available, it shall be modified so that it does the dereference by CPU
hardware.
--
Mit freundlichen Gr��en
Xu�n Baldauf
Medium.net Internet Server Software
