From 6ec8bf6b20aa33b1f55879b41f75b1470504f74e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 28 Apr 2015 16:01:18 -0400 Subject: comment --- ...ent_6_545e1c26a042b9f8347496a1bfb61548._comment | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment diff --git a/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment b/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment new file mode 100644 index 00000000..29b07e5c --- /dev/null +++ b/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment @@ -0,0 +1,48 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2015-04-28T19:24:12Z" + content=""" +I've followed the same path in the wip-bytestring-privdata branch. + +It needs to round trip through String anyway to handle Read/Show +serialization the same as before. I think this is doable without falling +over on invalid encodings, but it's certianly ugly. + +And yeah, changing Line to ByteString and all the other follow-on changes +just don't seem right. Everything that uses withPrivData would need to deal +with it being a ByteString, and would need to worry about encoding problems +when it needed to convert to a String, or Text, or whatever. + +So this feels like kicking the can down the road in the wrong direction... + +---- + +Maybe it would be better to handle this by adding a type to wrap up an +encoded ByteString in the PrivData. Could use base64 or something like +that for the encoding. Then only consumers of these ByteStrings would be a +little complicated by needing to unwrap it. + +Then it would be handly to give --set, --dump and --edit some +special handling of fields encoded like that. They could operate on raw +ByteStrings when handling such fields, and take care of the encoding +details. + +Add a new constructor to PrivDataField for binary files: + + | PrivBinaryFile FilePath + +And a function to get the encoder and decoder: + + type Encoder = ByteString -> PrivData + type Decoder = PrivData -> ByteString + + privDataEncoding :: PrivDataField -> Maybe (Encoder, Decoder) + +Then --set, --dump, and --edit could use that to encode and decode the +data. + +And finally, a `withBinaryPrivData` that uses ByteString. + +(Maybe this could be made more type safe though..) +"""]] -- cgit v1.2.3