If you're reading this commit history, please avert your eyes. 3
commits to fix this admittedly simple problem is more than my pride can handle.
The `gun.Back()` function was only searching for `opt`, not
`opt.file`. It would stop at the first mention of `opt` even if it
didn't have settings for `file`. Now it won't.
The FileJS module can be passed options in two ways, and this commit
ensures they're treated in the right way.
Previously, options passed as .put or .get parameters would be favored
over those used on the chain, even if `file` wasn't specified. Now, the
module will only use the method options if `file` is mentioned, falling
back to the chain options.
This was a mistake on my part with the first PR (#268), I failed to notice notice that edge case.
If you use gun a bunch, you've probably noticed the messages like "Hello
wonderful person :)" and "WARNING: This file.js module...".
This PR allows you to silence them.
Use `Gun.log.off = true` to bring peace back to your workflow.
> **Note:** great when used with file watchers like nodemon."
If the most recent gun options disable the file module, then it
won't try to read/write from the json. Previously it would. Also, now
you can override the behavior by passing `{ file: false }` as the
options in `gun.put`.
Servers will now try to initiate a connection using websockets if the
`peers` option is set. Currently, it'll either start throwing errors,
or generate a broadcasting storm. Still work to be done...
This marks a milestone of getting the servers to connect to each
other. Now to have those messages make sense. Committing so I
have an easy rollback point.
The `wsp.server` logic was never making it to the /gun.js route. If the
browser is just sending a GET request for a the js file, it won't set
the upgrade property, and the server logic wouldn't let the request pass
if it didn't have that header.
I've simply moved the check below the file serving logic.
