summaryrefslogtreecommitdiff
path: root/doc/todo/bytes_in_privData__63__
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/bytes_in_privData__63__')
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment19
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment7
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment7
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment19
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment15
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_6_545e1c26a042b9f8347496a1bfb61548._comment48
-rw-r--r--doc/todo/bytes_in_privData__63__/comment_7_d6c4c2645696eac448e906d812c2de62._comment25
7 files changed, 140 insertions, 0 deletions
diff --git a/doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment b/doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment
new file mode 100644
index 00000000..5c1508fd
--- /dev/null
+++ b/doc/todo/bytes_in_privData__63__/comment_1_42c107179b091f74ef55aff1fc240c5e._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-20T01:04:26Z"
+ content="""
+I imagine that adding `fileEncoding stdin` to setPrivData will fix
+this crash, but I'd expect there are also other problems with encodings
+for privdata that haskell doesn't like. Similar fixes would probably
+be needed in several other places.
+
+Probably cleaner and better to convert
+`PrivData` from a String to a ByteString, and so avoid encodings
+being applied to it. I think this could be done without changing the
+file format; the privdata file uses Read/Show for serialization,
+and happily ByteString uses the same Read/Show format as String does.
+
+So, changing the type and following the compile errors should get you
+there, I think!
+"""]]
diff --git a/doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment b/doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment
new file mode 100644
index 00000000..10ff956a
--- /dev/null
+++ b/doc/todo/bytes_in_privData__63__/comment_2_60f577b476adc6ee1e4f18e11843df90._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="gueux"
+ subject="comment 2"
+ date="2015-04-21T12:59:42Z"
+ content="""
+Would you accept a patch converting PrivData from String to ByteString?
+"""]]
diff --git a/doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment b/doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment
new file mode 100644
index 00000000..a1c7f62f
--- /dev/null
+++ b/doc/todo/bytes_in_privData__63__/comment_3_55f34128de77b7947d32fac71071e033._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-21T16:52:06Z"
+ content="""
+Absolutely. Thought that went w/o saying. ;)
+"""]]
diff --git a/doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment b/doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment
new file mode 100644
index 00000000..bd7a0618
--- /dev/null
+++ b/doc/todo/bytes_in_privData__63__/comment_4_f34a8f82c7bce7224e4edc59410c741f._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="gueux"
+ subject="comment 4"
+ date="2015-04-23T09:21:07Z"
+ content="""
+I tried to do the conversion, but then it started a kind of chain reaction... (PrivData=ByteString to writeFileProtected to Line=ByteString to ... to readProcess to ...) Should I use FilePath=String? ... To be honest, the patch became a lot bigger that what I am comfortable with. :-)
+
+I guess you should have a look at it...
+
+At least, I think there is a type bug in Propellor.Property.File:
+
+ hasPrivContent' :: (IsContext c, IsPrivDataSource s) => (String -> FilePath -> IO ()) -> s -> FilePath -> c -> Property HasInfo
+
+but it should be
+
+ hasPrivContent' :: (IsContext c, IsPrivDataSource s) => (FilePath -> String -> IO ()) -> s -> FilePath -> c -> Property HasInfo
+
+(it is hidden by FilePath = String)
+"""]]
diff --git a/doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment b/doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment
new file mode 100644
index 00000000..45c97b97
--- /dev/null
+++ b/doc/todo/bytes_in_privData__63__/comment_5_f4db6ffad054feb7eb299708fcd7d05c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-04-23T13:25:50Z"
+ content="""
+Can you put the patch up somewhere? I'll take a look. Might see a way to
+short-curcuit the bytestring before everything becomes one..
+
+One way might be:
+
+ writeFileProtected :: FileContent content => FilePath -> content -> IO ()
+
+Which would also at least partly avoid foot-shooting over which parameter is which.
+(Fixed that type signature.)
+"""]]
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..)
+"""]]
diff --git a/doc/todo/bytes_in_privData__63__/comment_7_d6c4c2645696eac448e906d812c2de62._comment b/doc/todo/bytes_in_privData__63__/comment_7_d6c4c2645696eac448e906d812c2de62._comment
new file mode 100644
index 00000000..07bc8145
--- /dev/null
+++ b/doc/todo/bytes_in_privData__63__/comment_7_d6c4c2645696eac448e906d812c2de62._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""mostly done"""
+ date="2015-09-15T00:26:10Z"
+ content="""
+A recent change converted PrivData to a newtype.
+There are no longer any things that directly use PrivData; all use
+should be via accessor functions like privDataLines and privDataVal.
+Which helps with this.
+
+So, I've instead implemented a `privDataByteString :: PrivData -> ByteString`,
+and I've adjusted the privdata serialization so it shouldn't crash
+on arbitrarily encoded data when eg, a binary file is fed into `propellor --set`.
+
+(Note that I was wrong earlier when I said it'd be safe to change the
+serialization to use ByteString; it must use String. While `"foo"`
+can be Read as a ByteString same as a string, `"foo\1000"`,
+when Read as a ByteString, truncates the big unicode character to
+a single byte. So, PrivData is still stored as Strings internally.)
+
+The final step would be to make `hasPrivContent` use `privDataByteString`
+instead of `privDataLines`. Which needs some more work to add Properties to
+ensure a file contains a ByteString. This should be pretty easy to do,
+but I lost steam..
+"""]]