Re: [ba-unrev-talk] Immutable Granular Addressability: Rehash?
> > - Their display of the document is purplized. The purple number is
> > short, globally unique, persistent, and not associated with the
> > parent document. That is, it is its own URL. It is the id of the
> > node. (01)
Another comment, similar to the first:
All current browsers work on URI path information to navigate to a specific node
address *within* a document.
It sounds like what you say above breaks that.
?? (02)
--
Peter (03)
----- Original Message -----
From: "Peter Jones" <ppj@concept67.fsnet.co.uk>
To: <ba-unrev-talk@bootstrap.org>
Sent: Monday, October 07, 2002 10:38 PM
Subject: Re: [ba-unrev-talk] Immutable Granular Addressability: Rehash? (04)
> Comment: On the assumption that I've understood what you're saying properly...
>
> It looks like a node has to know its version history list, its parent(s), and
> its position(s) in any parent-children list(s).
>
> O...K... (sounds a lot like Lee Iverson's NODAL)
>
> > - Their display of the document is purplized. The purple number is
> > short, globally unique, persistent, and not associated with the
> > parent document. That is, it is its own URL. It is the id of the
> > node.
>
> Cf. my mail about Purple Numbers and Transclusions
> http://www.bootstrap.org/lists/ba-unrev-talk/0210/msg00045.html
>
> I hope to place further comments about purple numbering on the list shortly
that
> might provide more handles on matters.
>
> Cheers,
> --
> Peter
>
>
> ----- Original Message -----
> From: "Chris Dent" <cdent@burningchrome.com>
> To: <ba-unrev-talk@bootstrap.org>
> Sent: Monday, October 07, 2002 9:47 PM
> Subject: Re: [ba-unrev-talk] Immutable Granular Addressability: Rehash?
>
>
> > On Mon, 7 Oct 2002, SAsites wrote:
> >
> > > I was aware of Purple's dkr and version control (via eekim's Intro
> > > to Purple), but I wasn't aware until just now about this post Eugene
> > > made some time back:
> > > http://www.bootstrap.org/dkr/discussion/3466.html. Perhaps my
> > > "solution" is a rehash, but maybe we need reexamine this whole issue
> > > of immutable links and brain storm it a bit.
> >
> > Eugene and I have been arguing for a while now on what ought to happen
> > when the data to which a purple number points changes.
> >
> > I've heard enough from him now to think it is an acceptable (although
> > perhaps not ideal) solution to have purple numbers point to the
> > version of data that was present when the purple number was created.
> > However any solution, such as using an external system of cached or
> > archived documents, that does not provide any knowledge of the data
> > behind the purple number changing is a more serious flaw that simply
> > not ideal.
> >
> > This problem keeps rolling back to versioned documents and it is
> > galling that Nelson and Engelbart seem to have had this one worked out
> > long ago but now here in this day and age we are struggling to work
> > the concepts into systems that are embedded into the culture.
> >
> > Sigh.
> >
> > That said, for the sake of brainstorming, I can think a possible
> > solution, harder to implement, is one that uses an internal archive
> > with purple slurple. There are probably enormous IP issues with this,
> > but you might be able to get around by only storing metadata rather
> > that content. What I'm about to describe sounds like something
> > somebody in the XML world has either thought about or done, but I'm
> > not familiar with that world. And it also sounds like something that
> > would have come up on this list a few times, but that's never stopped
> > anyone else so I won't let it stop me:
> >
> > - PurpleSlurple is a proxy riding on top of a database.
> >
> > - When a user gets a URL via the proxy the proxy first looks in its
> > cache and doesn't find it, so it gets the content and stores it in a
> > database.
> > - In the database the content is represented as a series of nodes
> > - The user gets a (short, globablly unique, persistent) URL representing
> this
> > version of the document.
> > - Their display of the document is purplized. The purple number is
> > short, globally unique, persistent, and not associated with the
> > parent document. That is, it is its own URL. It is the id of the
> > node.
> >
> > - If the proxy does have the document and it is as new as the modified
> > time of the original content, it looks at the list of document IDs
> > it has associated with the URL and returns the top of the stack,
> > rewriting the URL to the persistent URL representing that doc id.
> >
> > - If the original version has been modified the magic that I haven't
> > figured out yet does a sort of diff to reuse existing purple node
> > ids for generating the document, creating new as necessary.
> >
> > - If a user makes a request of the proxy by document ID, the document
> > is framed by a list of older and newer versions.
> >
> > - If a user makes a request of the proxy by purple ID, the node is
> > displayed, framed by
> > - access to the rest of the document at that moment in time
> > - access to the rest of the versions of this particular node
> >
> > In this model the stored purple id must knows its parent id (or ids?).
> >
> > The magic part in the middle is the same hard problem that all these
> > ideas have.
> >
> > Seeems like Google should have the resources to do this. Anybody have
> > an inside track to labs.google.com? If they were convinced that
> > purple is cool, I can see them doing it.
> >
> > Anyway, those are some loose Monday thoughts. Comments?
> >
> > --
> > Chris Dent <cdent@burningchrome.com> http://www.burningchrome.com/~cdent/
> > "If you assume that there is an instinct for freedom, that there are
> > opportunities to change things, that hope is possible, then hope may be
> > justified, and a better world may be built. That's your choice." N.Chomsky
> >
> >
>
> (05)