wai 0.4.3 → 1.0.0

raw patch · 2 files changed

+51/−26 lines, 2 filesdep +conduitdep +vaultdep −enumeratorPVP ok

version bump matches the API change (PVP)

Dependencies added: conduit, vault

Dependencies removed: enumerator

API changes (from Hackage documentation)

Files

• Network/Wai.hs +48/−24
• wai.cabal +3/−2

@@ -39,8 +39,7 @@     ( -- * WAI interface       Request (..)     , Response (..)-    , ResponseEnumerator-    , responseEnumerator+    , responseSource     , Application     , Middleware     , FilePart (..)@@ -51,15 +50,17 @@ import qualified Data.ByteString as B import qualified Data.ByteString.Lazy as L import Data.Typeable (Typeable)-import Data.Enumerator (Enumerator, Iteratee (..), ($$), joinI, run_)-import qualified Data.Enumerator as E-import qualified Data.Enumerator.List as EL-import Data.Enumerator.Binary (enumFile, enumFileRange)-import Blaze.ByteString.Builder (Builder, fromByteString, fromLazyByteString)+import Control.Monad.Trans.Resource (ResourceT)+import qualified Data.Conduit as C+import qualified Data.Conduit.List as CL+import qualified Data.Conduit.Binary as CB+import Blaze.ByteString.Builder (Builder, fromLazyByteString) import Network.Socket (SockAddr) import qualified Network.HTTP.Types as H import Data.Text (Text) import Data.ByteString.Lazy.Char8 () -- makes it easier to use responseLBS+import Blaze.ByteString.Builder (fromByteString)+import Data.Vault (Vault)  -- | Information on the request sent by the client. This abstracts away the -- details of the underlying implementation.@@ -94,13 +95,39 @@   ,  pathInfo       :: [Text]   -- | Parsed query string information   ,  queryString    :: H.Query+  ,  requestBody    :: C.Source IO B.ByteString+  -- | A location for arbitrary data to be shared by applications and middleware.+  , vault           :: Vault   }-  deriving (Show, Typeable)+  deriving (Typeable) +-- |+--+-- Some questions and answers about the usage of 'Builder' here:+--+-- Q1. Shouldn't it be at the user's discretion to use Builders internally and+-- then create a stream of ByteStrings?+--+-- A1. That would be less efficient, as we wouldn't get cheap concatenation+-- with the response headers.+--+-- Q2. Isn't it really inefficient to convert from ByteString to Builder, and+-- then right back to ByteString?+--+-- A2. No. If the ByteStrings are small, then they will be copied into a larger+-- buffer, which should be a performance gain overall (less system calls). If+-- they are already large, then blaze-builder uses an InsertByteString+-- instruction to avoid copying.+--+-- Q3. Doesn't this prevent us from creating comet-style servers, since data+-- will be cached?+--+-- A3. You can force blaze-builder to output a ByteString before it is an+-- optimal size by sending a flush command. data Response     = ResponseFile H.Status H.ResponseHeaders FilePath (Maybe FilePart)     | ResponseBuilder H.Status H.ResponseHeaders Builder-    | ResponseEnumerator (forall a. ResponseEnumerator a)+    | ResponseSource H.Status H.ResponseHeaders (C.Source IO Builder)   deriving Typeable  data FilePart = FilePart@@ -108,26 +135,23 @@     , filePartByteCount :: Integer     } deriving Show -type ResponseEnumerator a =-    (H.Status -> H.ResponseHeaders -> Iteratee Builder IO a) -> IO a--responseEnumerator :: Response -> ResponseEnumerator a-responseEnumerator (ResponseEnumerator e) f = e f-responseEnumerator (ResponseFile s h fp mpart) f =-    run_ $ (maybe enumFile enumFilePart) mpart fp $$ joinI-         $ EL.map fromByteString $$ f s h-responseEnumerator (ResponseBuilder s h b) f = run_ $ do-    E.yield () $ E.Chunks [b]-    f s h+responseSource :: Response -> (H.Status, H.ResponseHeaders, C.Source IO Builder) -- FIXME re-analyze usage of Builder+responseSource (ResponseSource s h b) = (s, h, b)+responseSource (ResponseFile s h fp (Just part)) =+    (s, h, sourceFilePart part fp C.$= CL.map fromByteString)+responseSource (ResponseFile s h fp Nothing) =+    (s, h, CB.sourceFile fp C.$= CL.map fromByteString)+responseSource (ResponseBuilder s h b) =+    (s, h, CL.sourceList [b]) -enumFilePart :: FilePart -> FilePath -> Enumerator B.ByteString IO a-enumFilePart (FilePart offset count) fp =-    enumFileRange fp (Just offset) (Just count)+sourceFilePart :: FilePart -> FilePath -> C.Source IO B.ByteString+sourceFilePart (FilePart offset count) fp =+    CB.sourceFileRange fp (Just offset) (Just count)  responseLBS :: H.Status -> H.ResponseHeaders -> L.ByteString -> Response responseLBS s h = ResponseBuilder s h . fromLazyByteString -type Application = Request -> Iteratee B.ByteString IO Response+type Application = Request -> ResourceT IO Response  -- | Middleware is a component that sits between the server and application. It -- can do such tasks as GZIP encoding or response caching. What follows is the

@@ -1,5 +1,5 @@ Name:                wai-Version:             0.4.3+Version:             1.0.0 Synopsis:            Web Application Interface. Description:         Provides a common protocol for communication between web applications and web servers. License:             BSD3@@ -20,10 +20,11 @@   Build-Depends:     base                      >= 4        && < 5                    , bytestring                >= 0.9.1.4  && < 0.10                    , blaze-builder             >= 0.2.1.4  && < 0.4-                   , enumerator                >= 0.4.8    && < 0.5+                   , conduit                   >= 0.1                    , network                   >= 2.2.1.5  && < 2.4                    , http-types                >= 0.6      && < 0.7                    , text                      >= 0.7      && < 0.12                    , transformers              >= 0.2.2    && < 0.3+                   , vault                     >= 0.1      && < 0.2   Exposed-modules:   Network.Wai   ghc-options:       -Wall