dch
-
Posts
4 -
Joined
-
Last visited
Posts posted by dch
-
-
The solution is to consider something like the draft IETF standard, and develop towards that http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol/ instead using a public, open, protocol, at the core. Contact me offline if interested in discussing this further, its not really appropriate for the sync forum. twitter:@dch__
-
For example:
[1] + 33469 bus error /Applications/BTSync.app/Contents/MacOS/btsync --config
If the directory specified for the pidfile is missing, or the storage_path isn't accessible, or AFAICT the pseudo-JSON you are using isn't valid.
I'd strongly advise dropping the `// comments` from the format, and enabling us to use normal JSON parsers and validators to manage this.
-
Either set up a launchd plist, for example here's one for Apache CouchDB:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"> <dict> <key>Label</key> <string>org.apache.couchdb</string> <key>EnvironmentVariables</key> <dict> <key>HOME</key> <string>/usr/local/var/lib/couchdb/</string> </dict> <key>ProgramArguments</key> <array> <string>/usr/local/bin/couchdb</string> </array> <key>UserName</key> <string>couchdb</string> <key>StandardOutPath</key> <string>/dev/null</string> <key>StandardErrorPath</key> <string>/dev/null</string> <key>RunAtLoad</key> <true/> <key>KeepAlive</key> <true/> </dict></plist>
modify this file as needed, put it in `/Library/LaunchDaemons/com.bittorrent.btsync.plist` and then use
`/usr/bin/sudo launchctl load -w /Library/LaunchDaemons/com.bittorrent.btsync.plist` to start it
and
`/usr/bin/sudo launchctl unload /Library/LaunchDaemons/com.bittorrent.btsync.plist` to stop it
Alternatively, run it when you need it from the terminal:
/Applications/BitTorrent\ Sync.app/Contents/MacOS/BitTorrent\ Sync-config ~/btconfig/config.json &
the & forces it to run in the background.
Http Api Content-Type Not Respected
in Developers
Posted
Request Headers. Note Accept.
Response Headers. Note Content-Type.
Content-Type should obviously be application/json -- we are not returning arbitrary JavaScript (aka JSONP) here.
This should be fixed because:
1. sent content-type should match the requested type within reason
2. it's clearly application/json data being returned anyway
3. downstream APIs and tools may not handle text/javascript in the same way
This specific example taken from FreeBSD 10.0 client. I'd suggest also you may want to consider including the btsync version in the returned headers. This will be useful in future for feature detection and operations.