From 1b2db0599f76ff9504b6f4125876b4101d1ad4bb Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 25 Dec 2013 18:22:17 -0400 Subject: devblog --- ...85__external_special_remote_protocol_types.mdwn | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/devblog/day_85__external_special_remote_protocol_types.mdwn (limited to 'doc/devblog') diff --git a/doc/devblog/day_85__external_special_remote_protocol_types.mdwn b/doc/devblog/day_85__external_special_remote_protocol_types.mdwn new file mode 100644 index 000000000..f8d7f4270 --- /dev/null +++ b/doc/devblog/day_85__external_special_remote_protocol_types.mdwn @@ -0,0 +1,25 @@ +Only did a few hours today, getting started on implementing the +[[design/external_special_remote_protocol]]. + +Mostly this involved writing down types for the various messages, +and code to parse them. I'm very happy with how the parsing turned out; +nearly all the work is handled by the data types and type classes, +and so only one line of very simple code is needed to parse each message: + +[[!format haskell """ +instance Receivable Response where + parseCommand "PREPARE-SUCCESS" = parse0 PREPARE_SUCCESS + parseCommand "TRANSFER-SUCCESS" = parse2 TRANSFER_SUCCESS + parseCommand "TRANSFER-FAILURE" = parse3 TRANSFER_FAILURE +"""]]] + +An especially nice part of this implementation is that it knows exactly how +many parameters each message should have (and their types of course), and so +can both reject invalid messages, and avoid ambiguity in tokenizing the +parameters. For example, the 3rd parameter of TRANSFER-FAILURE is an error +message, and as it's the last parameter, it can contain multiple words. + + *Remote.External> parseMessage "TRANSFER-FAILURE STORE SHA1--foo doesn't work on Christmas" :: Maybe Response + Just (TRANSFER_FAILURE Upload (Key {keyName = "foo", keyBackendName = "SHA1", keySize = Nothing, keyMtime = Nothing}) "doesn't work on Christmas") + +That's the easy groundwork for external special remotes, done. -- cgit v1.2.3