[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

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)