This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
`Spiderable.requestTimeout` can now be changed in server code in an app
to the number of milliseconds to wait until spiderable gives up on
phantomjs.
This is motivated by frontpage hitting 15 seconds at times (due to some
other problem we have), but regardless slow page loads are better than
non-crawlable ones.
Resolves#3824
Adds missing `DDP` dependancy
Adds `callback-hook` for onReady hook registration
Adds some client tests for `Spiderable`
Bumps version to `1.0.8`
Since the browser application cache appears not to support URL path
routes in a non-buggy way (see
https://github.com/meteor/meteor/pull/2926), applications using the
appcache package will want to use hash fragment routes instead.
This PR adds support to the spiderable package for hash fragment
routes. An original URL such as `http://example.com/#!a=1&b=2` will
be encoded by a search engine as an escaped fragment, decoded by the
spiderable package, passed through to the phantomjs process, and
appear to the phantom client as `#!a=1&b=2` in `window.location.hash`
(the same as when the original URL is opened in a regular browser).
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
Other approaches seemed to be heuristics that broke down in edge cases:
a timeout wasn't guaranteed if your JS was slow; page.load in PhantomJS
wasn't firing reliably because of long polling.
Until I made this I always got only ```<head/>``` with it's content, ```<body>``` was empty.
It seems setInterval script was finished earlier then url content was loaded to the page. Maybe because I have subscriptions with response time lower then 100ms so they were ready very quickly — database server in the same data center.
http://phantomjs.org/api/webpage/method/open.html
