Hey Greg, Thanks for the feedback, just one more question (bellow) about reading the files the tester is providing...
2011/2/26 Gregory Collins <[email protected]> Hi Román, > > 2011/2/25 Román González <[email protected]>: > > > Now RequestBuilder, is implemented like this > > > newtype RequestBuilder a = RequestBuilder (State RequestProduct a) > deriving > > Monad > > data RequestProduct = RequestProduct { > > rqpParams :: Params > > , rqpFileParams :: Params > > , rqpHeaders :: Headers > > , rqpIsSecured :: !Bool > > } deriving (Show) > > I assume this is the plan (current version doesn't look like this), and > that > "rqpFileParams" should be "FileParams". That looks good to me -- it allows > you > to specify the file parts declaratively and have a Request built out of > that, > which is nice. > > > > Right now, I'm stuck on building the final multipart request body, > specially: > > > > - Reading the contents of the files given by the developer on the Test > API > > I'm not sure I follow you here: what specifically is the problem? > I think I'm wondering where are we going to read the files, would we be requiring the tester to provide a full URI for the File location? get' "/my-upload" [] $ do addFile "photo" "/tmp/file.jpg" Or are we going to have like a SNAP_ROOT where all the paths will go get' "/my-upload" [] $ do addFile "photo" "tmp/file.jpg" -- this go to SNAP_ROOT/tmp/file.jpg > > > - Building Random Boundary values for the multipart request > > I would say this is not especially important, I didn't bother in the > blackbox > file upload tests for snap-server. If you really want to go with a > randomly-generated boundary, I suggest something like I did for the random > input in snap-server: > > > https://github.com/snapframework/snap-server/blob/master/test/suite/Test/Blackbox.hs#L213 > > That is, generate a bunch of random Word8 values and encode them as > base-16. > > > > Probably the code could be better (or faster) by using a Builder on the > > multipart functions? I didn't use it given that I'm not familiar with the > > API and I wanted to have something done to show. > > Builders are actually quite easy; just use the Builder Monoid instance. > Where > you have: > > S.concat [ "--" > , boundary > , "\r\n" > , "Content-Disposition: form-data; name=\"" > , name > , "\"; filename=\"" > , fName > , "\"\r\n" > , "Content-Type: " > , fileType defaultMimeTypes (S.unpack fName) > , "\r\n\r\n" > , fContent > , "\r\n" > ] > > Replace that with: > > toByteString $ > mconcat [ fromByteString "--" > , fromByteString boundary > .... > ] > > If all you have is bytestring values, Builder will not actually be much > more > efficient than S.concat (because S.concat is smart), but where you'll win > is in > serializing things like Maps, etc; having: > > mapToBuilder :: Map Foo Bar -> Builder > > is guaranteed to be more efficient than turning the map into a bytestring > and > then using "S.concat" to concat that string with other stuff, you'll save a > copy or two. > > For testing code I don't think it matters much, performance is not > paramount > there. > > G > -- > Gregory Collins <[email protected]> >
_______________________________________________ Snap mailing list [email protected] http://mailman-mail5.webfaction.com/listinfo/snap
