Re: [ba-unrev-talk] Immutable Granular Addressability: Rehash?
On Mon, 7 Oct 2002, SAsites wrote: (01)
> 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. (02)
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. (03)
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. (04)
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. (05)
Sigh. (06)
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: (07)
- PurpleSlurple is a proxy riding on top of a database. (08)
- 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. (09)
- 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. (010)
- 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. (011)
- If a user makes a request of the proxy by document ID, the document
is framed by a list of older and newer versions. (012)
- 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 (013)
In this model the stored purple id must knows its parent id (or ids?). (014)
The magic part in the middle is the same hard problem that all these
ideas have. (015)
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. (016)
Anyway, those are some loose Monday thoughts. Comments? (017)
--
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 (018)