On Sun, May 07, 2000 at 10:26:00PM -0400, Travis Bemann wrote: > On Sun, May 07, 2000 at 01:08:01PM +0100, Ian Clarke wrote: > > > > > The basic issue is how to update content. A versioning system would not > > > allow any document to be modified or deleted to be replaced by a newer > > > version. The old version would hang around the system until it was > > > eventually dropped from the datastore, or not if it was popular enough. > > > Two capabilities need to be provided. The ability to retrieve the > > > latest version of the document automatically and the ability to access a > > > specific version. > > > > > > To retrieve a later version of a document, you should be able to make > > > another request using the same search key. If Freenet encounters two > > > versions of the same document using the same key, it should return the > > > newer one. This implies that the version information is seperate from > > > the plaintext the search key is hashed from. One option is to make a > > > 'Version' header field. > > > > Ok, the problem here is that if you have numerous documents all with the > > same key then you can't use Freenet's routing mechanism to find all > > version, in fact, you can never be sure you have found the latest > > version. Further, how can you specify what version you are looking > > for? The node which attempts to answer your request probably won't have > > all of the versions to start with. > > > > The way I would approach this gives the same functionality, but doesn't > > require such an upheaval in the way things operate. Each new version of > > a document would be stored under a key like "documentname/0.2", and then > > the key "documentname" would redirect to the latest version (this > > obviously required that we have implemented data modification and > > redirection - both of which are on the radar). > > > > Ian. > > This would require either searching that looks beyong the nearest node or > messages which would be broadcast whenever a new version of a document was > created. Even redirection to the latest version would require this. > > I propose the creation of a new message type: > > Broadcast.NodeUpdate Whoops! I should have written Data.UpdateBroadcast
> with the attributes: > > UniqueID= ID unique to this message (does not change when message is passed > on) > DataKey= data key (if this isn't the name of the same attribute for the > other messages, this should be changed) > DataVersion= version of the updated document > > When a document is updated, the node which received the message to update > the document should send this message to all the other nodes that it knows > of. When a node receives this message (if it hasn't received it before, > which can be determined by the UniqueID), it passes it onto all the other > nodes that it knows of, except for the node that it received this message > from. > > > _______________________________________________ > > Freenet-dev mailing list > > Freenet-dev at lists.sourceforge.net > > http://lists.sourceforge.net/mailman/listinfo/freenet-dev > > -- > Travis Bemann > Sendmail is still misconfigured on my box. > My email address is really bemann at execpc.com > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Travis Bemann Sendmail is still misconfigured on my box. My email address is really bemann at execpc.com _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
