pathnames

[Alaric B. Williams]

> >I think that having a commit API would then make the two-level storage
> >nature of those objects that just happened to be in the user-level
> >"namespace" have to be dealt with differently, all of a sudden - they'd
> >have to be committed and all that.
> 
> Ok, I can see that your idea might at least be a useful
> option. Perhaps even a good default for hacking around at the command
> prompt, but I'd have to think about that. Most applications would want
> to have an explicit (commit) though at one strategically positioned
> point, which doesn't break the illusion too much.

Ok, then, that's doable. An implicit (commit) occurs at finalisation,
of course, and we're all set; an app can ignore committing, then,
although it wouldn't be recommended?

> >EG, the user-level repl loop is in fact a persistent object (maybe
> >called "/bin/sh", as a subtle irony :-), so everything inside it has
> >a home to go to when the system is powered down, but only the actual
> >environment object is registered as persistent, since it includes
> >everything else. It would have modification dates and all that, and
> >a user-level type. It's real type would be "executing environment
> >with a continuation", but it's user-level type could be "Command
> >line application".
 
> Yeah, but that means that there is only one object in the whole system
> which complies with your API - "/bin/sh". Everything else just happens
> to be attached. So what's the point?

I've gotten confused. What do you mean? There could be lots of these
objects of type "Command line application", each of which are environments
with continuations that expect to be connected to a console-like object
(hopefully in a CLIMish way?). A shell would be but one of them, and would
count as a User Agent under the security model I expounded elsewhere on this
list today.
 
> >> Versions? Well also don't forget that nice Lisp code is very
> >> functional, and not everything will have a clear correspondance to a
> >> version.
> >
> >It's nice for document management, 
> 
> Sure, document managment is a good use for it. But different apps will
> want to access versions differently. Documents probably want to be
> accessed by date. Program source by the release number. etc.

That's why you have both.

> And with documents, sometimes a document might consist of a number of
> different chapters in different "files". You probably don't want to
> version the individual bits and pieces because you've then lost track
> of how the whole document looked at any one point in time. (Anyone
> using source code control is familiar with this problem). What you
> want to do is version the whole "directory" (collection), and not
> bother versioning the bits and pieces. The versions of the bits and
> pieces just fall into line by versioning the collection.

Hmmm... that's doable, in that directories can have version too...
I just wonder how I'd API it :-)

> Basicly versioning is very application specific.

Agreed - however versions are done, the application altering the
object, or even better the object whose mutating methods are being
invoked, should decide how to identify each version (there is
a numbering, certainly, but additional data such as "draft" and
the revision date are added by the controlling code), and what
point in the development of the object counts as a version.
Hey, a commit API :-)
 
> >and the user-level POS is a very
> >stateful thing rather than functional.

[...]

> I've got in mind a function (chapter-edit) which takes a "Chapter" as
> argument and returns a new Chapter object as a result. The old version
> is not changed in true functional style. Another function (book-edit)
> takes a "Book" object as argument, and then calls (chapter-edit) to
> modify chapters. Instead of modifying the book object, (book-edit)
> makes a new book with the all the latest versions of the chapters and
> returns the new book object. The old version of the book object is
> left as-is. (In functional style)

Right. However, we want the most recent version to be pointed to by
the POS binding "my-book", which is the state thing, and the past versions
to be visible in some way to be looked at.

> All this propogating of the problem upwards has to stop at some
> point. Which point depends on how the user wants to view a logical
> unit of work. Probably it would stop at the book level.

Which would, of course, be decided by the particular context.
 
[...]
> >Agreed... so let the default be "no versioning", but make a special
> >"commit" API where persistent objects can give the OS a hint that
> >they're in a good state for a checkpoint right now. The OS can store
> >the list of versions as the "oldest version", then a list of
> >sets of differences from that.
> >When it decides to trim off some old versions, it updates the
> >"oldest version" with them, then drops them.
> 
> So how does the OS know which objects you want versioned? 

You have to tell it.

> What do you hope to gain by having a One True Versioning Algorithm?

What better versioning algorithms are there than keeping old versions,
submitted when the object says "I'm at a pretty steady state right now,
you can call it 'Draft version as of 9/5/1997'", huh?

> >Yes, but these user-level objects (which would map nicely to
> >segments in an OOFS from what I hear) are typically going to be
> >relatively large.
 
> How do you figure that they're going to be large? In actual fact, they
> will be extremely small. Take a document object for example. It would
> probably be a small structure containing a description, a date, and a
> pointer to the document itself. The actual document object consists of
> only 3 slots. An appropriate display-summary method would only print
> the description and date.

The document would go with it - all that text, the pictures, etc,
all in with the document "object". What made you distinguish between
them? I'd think of the document as an object, full stop...


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