113 |
Freenet has a rather peculiar combination |
Freenet has a rather peculiar combination |
114 |
of two workarounds [XXXref Freenet FAQ]: |
of two workarounds [XXXref Freenet FAQ]: |
115 |
|
|
116 |
In date-based updating, the key for the current version |
In date-based updating, the URI for the current version |
117 |
is formed by concatenating a document's id with the current date; |
is formed by concatenating a document's id with the current date; |
118 |
this requires publishers to insert versions of their document |
this requires publishers to insert versions of their document |
119 |
every day, otherwise they will not be accessible. |
every day, otherwise they will not be accessible. |
120 |
|
|
121 |
In edition-based updating, versions ``n`` and ``n+1`` |
In edition-based updating, a version's URI is the document's id |
122 |
have different URIs, but version ``n`` links to version ``n+1`` |
concatenated with a version number. Version ``n`` then links to |
123 |
using an ``<img>`` link; the image will not show until |
version ``n+1`` using an ``<img>`` link. The image will not show until |
124 |
version ``n+1`` is actually inserted into the system, so |
version ``n+1`` is actually inserted into the system; thus, |
125 |
if the image does show up, the user knows that they can click |
when the image does show up, the user knows that they should click |
126 |
on it to get to a newer version of the document. |
on it to get to a newer version of the document. |
127 |
|
|
128 |
Finally, a simplistic approach to P2P versioning |
Finally, a simplistic approach to P2P versioning |