Re: [ba-unrev-talk] Immutable Granular Addressability: Rehash?
Comment: On the assumption that I've understood what you're saying properly... (01)
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). (02)
O...K... (sounds a lot like Lee Iverson's NODAL) (03)
> - 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. (04)
Cf. my mail about Purple Numbers and Transclusions
http://www.bootstrap.org/lists/ba-unrev-talk/0210/msg00045.html (05)
I hope to place further comments about purple numbering on the list shortly that
might provide more handles on matters. (06)
Cheers,
--
Peter (07)
----- 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? (08)
> 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
>
> (09)