running 'ipfs serve' or 'ipfs serve http' prints the main help text (which shows 'serve' as a valid subcommand)
ipfs serve doesn't exist anymore, we need to update that main help text. There are also commands missing, like ipfs refs.
Ah, what is the equivalent now?
Now your API server will run a gateway by default
(localhost:5001/ipfs/<hash>). If you want a gateway without the API
server (so it can be run publicly), set the Addresses.Gateway field in
your config.
On Thu, Jan 15, 2015 at 11:45 AM, Jeromy Johnson [email protected]
wrote:
Ah, what is the equivalent now?
—
Reply to this email directly or view it on GitHub
https://github.com/jbenet/go-ipfs/issues/571#issuecomment-70148709.
we should simplify this with:
ipfs gateway start / root hash to gateway404 and 500)ipfs gateway {enable, disable}start tells the daemon to start gateway. this means assign a standard, and available port (try one in 80XX), save it in the config, and kick off the gateway. prints a URL, to a hash of an object they can use to test (like good old apache's "if you're seeing this, it's working!"). if the gateway was already running, this just prints the url and exits (idempotent)
stop halts the gateway and removes the url from the config (I can do this by turning the daemon command into using a daemon object with a sub process)
Also:
ipfs --help textSince we're adding the ipfs gateway command, do we still want the gateway to be running by default? We could have a Gateway.EnableByDefault key in the config.
I think the start and stop should toggle it. If you kill a daemon with the gateway on, starting the daemon on again should also start the gateway. Maybe instead of start and stop: enable and disable.
We've recently brought this issue back to a sprint discussion and everyone liked the idea of having start and stop as ipfs daemon subcommands
Indeed. Let's do it. Let's make start daemonize in the background? I guess
let's fully spec it out first
On Fri, Jan 1, 2016 at 19:40 David Dias [email protected] wrote:
We've recently brought this issue back to a sprint discussion and everyone
liked the idea of having start and stop as ipfs daemon subcommands—
Reply to this email directly or view it on GitHub
https://github.com/ipfs/go-ipfs/issues/571#issuecomment-168353100.
These two commands are part of the IPFS Core API now: https://github.com/ipfs/interface-ipfs-core, and help implementing this in go-ipfs is off course still welcome! :)
These two commands are part of the IPFS Core API now: https://github.com/ipfs/interface-ipfs-core, and help implementing this in go-ipfs is off course still welcome! :)
Sorry I might have been wrong about them being part of the Core API. Help still welcome!
Hi, I'm looking to contribute to the go-ipfs code base and I was wondering if this issue is still relevant? If not I would appreciate it if someone could point me in the right direction.
I would say this is not relevant anymore.
The command names have changed, but we have this in concept now.
ipfs daemon, ipfs shutdown, are the "start", "stop" equivalent.
If there's anything additional, for example, if someone wanted to expose shutdown over the coreapi, or if the command should have a different name, etc.
Then it should probably go in a new issue.
I think the difference is that ipfs start is ipfs daemon --background. I'll file a new issue for that as it's a frequent request (how do I start the daemon and know when it's ready?).
Most helpful comment
We've recently brought this issue back to a sprint discussion and everyone liked the idea of having
startandstopasipfs daemonsubcommands