From 657f833239f8a67cc554862ade81e74ed2610e28 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Tue, 2 Jun 2015 09:51:36 -0700 Subject: [PATCH] Fix 'trickle' -> 'layout' On Wed, May 27, 2015 at 10:44:32AM -0700, Jeromy Johnson wrote [1]: > ... the functionality you are referring to as 'trickle' is the > layout. the trickledag is a specific layout implementation that lays > out blocks in a pattern reminiscent of a recursive binomial heap. [1]: https://github.com/ipfs/go-ipfs/issues/1291#issuecomment-106009312 --- add-api.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/add-api.md b/add-api.md index 5b343e80c10..582470555f5 100644 --- a/add-api.md +++ b/add-api.md @@ -16,7 +16,7 @@ I'd suggest moving `core/coreunix` to `core/unixfs` to match // // p: The path from the add root to the just-created node. This // is empty for the root node. For large files and - // directories that are chunked and trickled, each chunk and + // directories that are chunked and laid-out, each chunk and // fanout node will have the same path argument. // f: A File reference for the file used to create nIn. Don't // seek this (which could throw off the chunker), but you can @@ -36,14 +36,14 @@ I'd suggest moving `core/coreunix` to `core/unixfs` to match // nIn: The just-created node // p: The path from the add root to the just-created node. This // is empty for the root node. For large files and - // directories that are chunked and trickled, each chunk and + // directories that are chunked and laid-out, each chunk and // fanout node will have the same path argument. // f: A File reference for the file used to create nIn. Don't // seek this (which could throw off the chunker), but you can // use it to extract metadata about the visited file including // its name, permissions, etc. This will be nil for // io.Reader-based adders. - // top: Whether or not nIn is the tip of a trickle DAG or an + // top: Whether or not nIn is the tip of a layout DAG or an // unchunked object. This allows you to distinguish those // nodes (which are referenced from a link with a user-visible // name) @@ -103,13 +103,14 @@ filename is left to the caller and the callback API. These should look just like the high-level API, except instead of passing in an IpfsNode and using that node's default DAG service, -trickler, and splitter, we pass each of those in explicitly: +layout, and splitter, we pass each of those in explicitly: - Add(ctx context.Context, ds dag.DAGService, t trickle.Trickler, s chunk.BlockSplitter, f *os.File, preNodeCallBack *PreNodeCallback, postNodeCallback *PostNodeCallback) (root *dag.Node, err error) - AddFromReader(ctx context.Context, ds dag.DAGService, t trickle.Trickler, s chunk.BlockSplitter, r io.Reader, preNodeCallBack *PreNodeCallback, postNodeCallback *PostNodeCallback) (root *dag.Node, error) + Add(ctx context.Context, ds dag.DAGService, layout _layout.Layout, s chunk.BlockSplitter, f *os.File, preNodeCallBack *PreNodeCallback, postNodeCallback *PostNodeCallback) (root *dag.Node, err error) + AddFromReader(ctx context.Context, ds dag.DAGService, layout _layout.Layout, s chunk.BlockSplitter, r io.Reader, preNodeCallBack *PreNodeCallback, postNodeCallback *PostNodeCallback) (root *dag.Node, error) -We don't currently have a public `Trickler` interface, but I think we should -add one so folks can easily plug in alternative trickler implementations. +We don't currently have a public `Layout` interface, but I think we +should add one so folks can easily plug in alternative layout +implementations. I'm not familiar enough with Go at the moment to know which arguments are best passed by reference and which should be passed by value. If