new protocol for transferkeys, with message serialization
authorJoey Hess <joeyh@joeyh.name>
Thu, 3 Dec 2020 20:21:20 +0000 (16:21 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 3 Dec 2020 20:21:20 +0000 (16:21 -0400)
commitcad147cbbf26ece5c85b84237919b352acd5cdf8
tree462748e4bf926bd72e7d3a889e899638301c759b
parent82dbc4387ccb3bec27788d920c94145024f928f0
new protocol for transferkeys, with message serialization

Necessarily threw out the old protocol, so if an old git-annex assistant
is running, and starts a transferkeys from the new git-annex, it would
fail. But, that seems unlikely; the assistant starts up transferkeys
processes and then keeps them running. Still, may need to test that
scenario.

The new protocol is simple read/show and looks like this:

TransferRequest Download (Right "origin") (Key {keyName = "f8f8766a836fb6120abf4d5328ce8761404e437529e997aaa0363bdd4fecd7bb", keyVariety = SHA2Key (HashSize 256) (HasExt True), keySize = Just 30, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}) (AssociatedFile (Just "foo"))
TransferOutput (ProgressMeter (Just 30) (MeterState {meterBytesProcessed = BytesProcessed 0, meterTimeStamp = 1.6070268727892535e9}) (MeterState {meterBytesProcessed = BytesProcessed 30, meterTimeStamp = 1.6070268728043e9}))
TransferOutput (OutputMessage "(checksum...) ")
TransferResult True

Granted, this is not optimally fast, but it seems good enough, and is
probably nearly as fast as the old protocol anyhow.

emitSerializedOutput for ProgressMeter is not yet implemented. It needs
to somehow start or update a progress meter. There may need to be a new
message that allocates a progress meter, and then have ProgressMeter
update it.

This commit was sponsored by Ethan Aubin
Assistant/TransferSlots.hs
Assistant/TransferrerPool.hs
Command/TransferKeys.hs
Messages.hs
Messages/Internal.hs
Messages/JSON.hs
Messages/Progress.hs
Types/Key.hs
Types/Messages.hs
doc/git-annex-transferkeys.mdwn