[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#33899] [PATCH 0/5] Distributing substitutes over IPFS
From: |
Ludovic Courtès |
Subject: |
[bug#33899] [PATCH 0/5] Distributing substitutes over IPFS |
Date: |
Mon, 15 Jul 2019 11:24:57 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hello Héctor! :-)
Hector Sanjuan <address@hidden> skribis:
> On Friday, July 12, 2019 10:15 PM, Ludovic Courtès <address@hidden> wrote:
[...]
>> > - Pinning: Pinning all files separately incurs an overhead. It's
>> > enough to just pin the IPLD object since it propagates recursively.
>> > When adding a tree, then it's no problem since pinning is only done
>> > once.
>> >
>>
>> Where’s the overhead exactly?
>
> There are reasons why we are proposing to create a single DAG with an
> IPLD object at the root. Pinning has a big overhead because it
> involves locking, reading, parsing, and writing an internal pin-DAG. This
> is specially relevant when the pinset is very large.
>
> Doing multiple GET requests also has overhead, like being unable to use
> a single bitswap session (which, when downloading something new means a
> big overhead since every request will have to find providers).
>
> And it's not just the web view, it's the ability to walk/traverse all
> the object related to a given root natively, which allows also to compare
> multiple trees and to be more efficient for some things ("pin update"
> for example). Your original idea is to create a manifest with
> references to different parts. I'm just asking you to
> create that manifest in a format where those references are understood
> not only by you, the file creator, but by IPFS and any tool that can
> read IPLD, by making this a IPLD object (which is just a json).
OK, I see. Put this way, it seems like creating a DAG with an IPLD
object as its root is pretty compelling.
Thanks for clarifying!
Ludo’.
[bug#33899] [PATCH 0/5] Distributing substitutes over IPFS, Molly Mackinlay, 2019/07/12