some interface was not exist in this api

[godcong]

I am sorry to be bothered many times.
now i has two questions:

1. in this package /api/v0/add was not found. will add this interface later?

2. (api *PinAPI) Ls(ctx context.Context, opts ...caopts.PinLsOption) has no arg parameter to input.
   i see the https://docs.ipfs.io/reference/api/http/#api-v0-pin-ls has it.
   and i neet it now. will add this parameter in this interface ?

[Stebalien]

1

api.Unixfs().Add(...)?

2

We'd probably add a new function. Something like Pin().Has(ctx, path) or Pin().IsPinned(...). Note: At least in the current implementation, this is unlikely to be any faster than simply listing all pins and checking if the target path is in the list of pinned paths.

[godcong]

api.Unixfs().Add(...)?

yes,it is. thanks.

We'd probably add a new function. Something like Pin().Has(ctx, path) or Pin().IsPinned(...).

perhaps i can help to do this, :)

Note: At least in the current implementation, this is unlikely to be any faster than simply listing all pins and checking if the target path is in the list of pinned paths.

at first,I have been using ipfs pin ls.
but when the db data is very large, it always suspended、did not return any information.
the rest api /api/v0/pin/ls has the same problem.(their implementation should be the same)
type of indirect is the most slowly.

So i think perhaps we need a pipeline interface to output informations,But I don't know if this is easy to implement.
or reduce the scope of the search. like add a Pin().IsPinned(...). interface.

[Stebalien]

What are you actually trying to do here?

[godcong]

What are you actually trying to do here?

for example:

1. i added and pinned some file at machineA,
2. then i pinned some hash at machineB, the hash is pinned on machineA.
3. at last, i want to check some hash from machineA ,
   These hashes,which pinned, which are not pinned with machineB.

1 and 2 have no problems, about step 3:

now an arguments of type recursive can let me get the pin list with a long time.
So why I want to use the arg parameter, it's the most quickly to get the result,
but i can only check one by one.
(pin ls looks a bit slow, i can't get any information when used default type)

(i make all these with a go application, so go-ipfs-http-client is required.)

Is there any good advice?

[Stebalien]

I can't understand what you're trying to say.

[godcong]

I only want to get the pin list.
but now (api *PinAPI) Ls(ctx context.Context, opts ...caopts.PinLsOption) has no response for me.

[Stebalien]

Got it. The issue is that it's recursively generating the pin list server-side.

• go-ipfs master (not released) can stream pins when passed the --stream flag.
• If you only want a list of files you've explicitly pinned, you can pass --type=recursive to ipfs pin ls. By default, ipfs pin ls prints out all pinned blocks, which includes everything referenced by a directly pinned file.

That's why I asked what you're trying to do. Unfortunately, ipfs pin ls SomeThing will also check if that thing is pinned indirectly (unless you pass --type=recursive or --type=direct). It's not going to be any faster than pin ls.

[godcong]

Got it. The issue is that it's recursively generating the pin list server-side.

Yes, as you said.
This is the problem I am having now.

go-ipfs master (not released) can stream pins when passed the --stream flag.

That's great, I saw it.
Does go-ipfs-http-client plan to add similar features in the future?
This seems to be a more complicated function for go-ipfs-http-client.

If you only want a list of files you've explicitly pinned, you can pass --type=recursive to ipfs pin ls. By default, ipfs pin ls prints out all pinned blocks, which includes everything referenced by a directly pinned file.

This feature is exactly what I am using now. No problem for the time being

That's why I asked what you're trying to do. Unfortunately, ipfs pin ls SomeThing will also check if that thing is pinned indirectly (unless you pass --type=recursive or --type=direct). It's not going to be any faster than pin ls.

Thanks for the explanation.

I found that our discussion seems to have deviated from the original theme.
The initial problem has been solved.
Although the functions discussed are all I want.
close this?

[Stebalien]

Does go-ipfs-http-client plan to add similar features in the future?

Yes. There's already a patch for github.com/ipfs/go-ipfs-api (ipfs/go-ipfs-api#190). However, that's blocked on releasing the feature in go-ipfs.

close this?

I've filed two issues:

#27
#28

If those cover it, let's close this one.

[godcong]

OK, thanks