ProviderEnv を作成する

See #98 .
See #111 .
See #112 .

二つの内部処理が似た関数のキャッシュをしたいときは (Map k v0, Map k v1) と Map k (These v0 v1) のどっちが効率がいいんですかね……？ -- https://twitter.com/hexirp_prixeh/status/1239174412974166016

取り敢えずは単純な前者を選びますが -- https://twitter.com/hexirp_prixeh/status/1239174557308575744

provider ディレクトリを先頭につけたパスを返す機能が必要なのかも考えないと。この機能はつまり provider ディレクトリのパスを取得できるようにするということ。

hexirp-hakyll/hexyll-core/src/Hexyll/Core/OldProvider/Internal.hs

Lines 154 to 159 in 412d19f

    
           -------------------------------------------------------------------------------- 
        
           -- | Get the raw body of a resource of a lazy bytestring 
        
           resourceLBS :: Provider -> Identifier -> IO BL.ByteString 
        
           resourceLBS p i = BL.readFile $ resourceFilePath p i

Body の方はキャッシュは不要で、今の所キャッシュする必要があるのは ModificationTime だけ。

実行途中に provider ディレクトリの中身が変わってしまう危険性を考えると……

ByteString は Lazy の方にした方がいいかもしれない。最後まで取得するまでハンドルが閉じないらしいし。

実行途中に provider ディレクトリの中身が変わってしまう危険性を考えると……パスは公開しない方がいいよね？

徹底すると http://hackage.haskell.org/package/conduit-1.0.8/docs/Data-Conduit-Binary.html みたいな方向性になるかもしれない。

Strict の方にする理由はあんまりなくて、メモリに全部乗ったら負担が大きいかもしれない。

http://hackage.haskell.org/package/conduit-extra-1.3.4/docs/Data-Conduit-Binary.html#v:sourceLbs

これが理想に近いというか何というか。

https://www.stackage.org/haddock/lts-15.3/base-4.13.0.0/System-IO.html#g:8

multiple-reader single-writer locking というロック戦略を使うらしい。複数の読み込み、または一つだけの書き込み。

ByteString を Lazy な方に変更する。全てのファイル名の取得の際に Set で返すように変更する。

	--------------------------------------------------------------------------------
	-- \| Get the raw body of a resource of a lazy bytestring
	resourceLBS :: Provider -> Identifier -> IO BL.ByteString
	resourceLBS p i = BL.readFile $ resourceFilePath p i