[Top][All Lists]

[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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]