Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Enabling experimental features #738

Closed
daviddias opened this issue Jan 29, 2017 · 6 comments
Closed

Enabling experimental features #738

daviddias opened this issue Jan 29, 2017 · 6 comments
Assignees
Labels
exp/expert Having worked on the specific codebase is important exploration P2 Medium: Good to have, but can wait until someone steps up

Comments

@daviddias
Copy link
Member

Following up #735 (comment)

We need a way to enable/disable experimental features throughout js-ipfs (that includes all the js-libp2p) in a way that is non-intrusive, easy to add and easy to remove, both in Node.js and the Browser.

A typical way to achieve this, is through env variables, but that might not be the ideal case for Browser bundles.

Thoughts, ideas?

@daviddias daviddias added the status/deferred Conscious decision to pause or backlog label Jan 29, 2017
@dignifiedquire
Copy link
Member

I think these options should be exposed as config options on a library level. We can then pass cli flags in js-ipfs as values for those (node.js) and simply set them directly when starting up the node in the browser. I would really like to stay away from global injections as much as possible for such things.

We could also reuse the existing config file, and add a section experimental, in which such things could be configured. This might be even nice for go-ipfs.

@daviddias
Copy link
Member Author

We are now supporting experimental features by passing flags to the options object on new IPFS.

Does everyone feel like this is resolved? If so, I'll close the issue :)

@haadcode
Copy link
Member

haadcode commented Aug 24, 2017

I feel the way it's done atm is good, ie. passing options to IPFS in the constructor.

That said, I agree with @dignifiedquire's comment that it'd be nice to have the experimental field in the config file as well (this may or may not have been implemented in the past couple of months, ignore if that's already the case).

I'm ok closing this as it is (we have a way to do it), and perhaps if we want to, add the experimental to the config, we can rename this issue or open a new one to track it's status.

@daviddias daviddias added status/in-progress In progress and removed status/deferred Conscious decision to pause or backlog labels Oct 17, 2017
@daviddias daviddias self-assigned this Oct 17, 2017
@daviddias
Copy link
Member Author

daviddias commented Oct 17, 2017

Last steps to complete this task:

  • Document how to enable experimental features
  • Support EXPERIMENTAL flags to be passed through config and not options. (so that daemons can also use them easily if needed)

@daviddias daviddias added exp/expert Having worked on the specific codebase is important P2 Medium: Good to have, but can wait until someone steps up labels Oct 17, 2017
@daviddias daviddias added status/deferred Conscious decision to pause or backlog and removed status/in-progress In progress labels Jan 25, 2018
@0x-r4bbit
Copy link
Contributor

@diasdavid happy to help out with those last tasks (if they still need to be done).

Any pointers where things should be documented?

@daviddias daviddias added status/ready Ready to be worked and removed status/deferred Conscious decision to pause or backlog labels Dec 9, 2018
@daviddias
Copy link
Member Author

This got done meanwhile. Thanks @PascalPrecht :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/expert Having worked on the specific codebase is important exploration P2 Medium: Good to have, but can wait until someone steps up
Projects
None yet
Development

No branches or pull requests

4 participants