Closed josephmturner closed 1 year ago
I would like to stick to information that's in the hyperdrive API as much as possible if that's okay with you.
If you need to get the drive at the current version, you should do a GET
on the root, and having the sequence number in the ETag for a file means that you can scroll through the version history by putting the sequence number into the version path without extra math.
Sticking to the hyperdrive API is a good idea. I suppose it's just a bit confusing that entry.seq
refers to the version of the hyperdrive before the entry was modified. According to MDN, "Typically, the ETag value is a hash of the content, a hash of the last modification timestamp, or just a revision number." In our case, wouldn't we expect the revision number to be the hyperdrive version after the entry was modified?
having the sequence number in the ETag for a file means that you can scroll through the version history by putting the sequence number into the version path without extra math.
This does simplify history traversal, but it also means that a UI for file metadata should probably increment entry.seq
by 1
before displaying the "file version number." Users should be able to load a file at the displayed "file version number" by loading hyper://PUBLIC-KEY/$/version/VERSION-NUMBER/example.txt
, and if we don't increment the ETag
value, that URL will instead load the file at the prior version. WDYT?
Since the HTTP ETag header traditionally is supposed to provide information about the current state of the returned file, could we just rename the ETag header to something like X-Hyperdrive-Last-Version
, while leaving the value what it is now? That way the label would be more descriptive and accurate, which would make writing clients easier, but it wouldn't require any extra work on the part of hypercore-fetch or hyperdrive.
I'm convinced and will make the changes monday. Principle of least surprise and all that
Oh sorry didnt see the lastest comment yet. Literally woke up for a bit to post 🤣
Great! Thank you :) Either solution works for the hyperdrive.el I think.
Resolved in 140cc1f.
Currently, the
ETag
header is set todrive.version
(orentry.seq
) of the drive before the file is added to the hyperdrive. Would it make more sense to set theETag
header to the version of the hyperdrive after the file is added?That way, if
example.txt
was last modified at version 50,HEAD
hyper://PUBLIC-KEY/example.txt
would giveETag
50
.This would mean that getting the version of a drive before the file was modified would require subtracting 1 from the
Etag
.