summaryrefslogtreecommitdiff
path: root/doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment
blob: 29b07e5cc2da3a1a7c2de70b4eec29a75c793c03 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
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..)
"""]]