pathnames

[Alaric B. Williams]

> >When it is finalised, the path object is told to close it down.
> >It does this by storing the string back to the file.
 
> This implys that things are stored back to disk in a non-deterministic
> fashion. That implys that in the event of system failure you have got
> no consistency of data whatsoever.
> 
> No, I think you have to do it properly and have a (commit) API.

Hmmm... that breaks the abstraction of persistent objects, though.
Although in the presence of multiple threads of execution,
some kind of commit API would be nice - the idea being that changes
to the object are entirely local (whatever local may be) until
you commit it. This programmer-level control of the sharing of
mutable objects should be more efficient than paranoid 
instant write-propogation...
 
> >Directories do things like return lists of the path objects
> >they contain - but their most important task is to accept
> >new objects.
 
> Why call it a directory then? It's just a data structure, like
> everything else in OOFS. It may be a list, hashtable, vector,
> structure, queue, btree or whatever.

It's expected to comply to a small API such as giving a POD
(persistent object description - name, type, versions available
with mod dates, etc) for any object it contains, etc.

This exists so we can be sure of providing a user-level representation
of what's in there, without having to actually access each object
(ie, by having a "represent-thyself" method), which would cause a load
of disk thrashing when we look into a directory!


ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html