-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iFrame loading #8
Comments
It needs to be the same origin as the comet endpoint that it's talking to; that's the point of having it. I agree about the versioning point. |
Ok, well we can modify the grunt build script later to reference a versioned iFrame. The only issue we then have is how does the Realtime system support the versions? It could proxy S3 to do this as our javascript deployer adds version numbers e.g. http://cdn.ably.io/lib/iframe-0.7.1.js |
The cdn service in the realtime system already proxies any request in We need to decide how the ably-js library decides which version of Then we need to make the grunt task that builds/minifies |
@paddybyers the versioning of the iframe.html file is automatically handled by our javascript deployer, it works in the exactly the same way as it does for the JS files by looking at the tagged version, so Grunt does not need to worry about that. However, in terms of the reference to the iFrame versioned file, that is indeed a bit trickier. Detecting the version number worries me a little as that means the URL to the Javascript file becomes meaningful, and that just doesn't feel right. However, getting Grunt to simply detect the tag and embed could be easy enough, however we'll need to perhaps then change our javascript deployment script to run the build before it deploys to ensure that the reference is indeed up to date as it's quite feasible you would build, commit, tag, and then deploy. WDYT? |
I agree that the deploy script, or a post-checkout hook, should perform the build instead of relying on prebuilt versions. The URL for |
Sure, commit ID should work, however if you build your script before you commit it will refer to the previous version so we'd need some discipline to build separately and commit. We could do that, and I could simply raise a warning if you're deploying ably-js with a reference to a SHA in a previous commit, WDYT? |
I was assuming that we would have a deploy remote which would do the build before deploying. |
@paddybyers could do, but a whole lot more work, so would prefer to do that down the line... |
Actually why don't we just have a build step that inserts the version string into the iframe url based on reading the package.json ? |
We could do that, but I didn't really like the idea that our deployment scripts deploys a file that is not the same as the static file compiled in our public Github repo. |
But that's the point - as part of building the static files it includes the version in the URL from the package.json. Then that build is repeatable and has no dependency on git, tags or revision. |
Ah, sorry, I misunderstood, sure, that sounds perfect. Can you make that change then? |
I've implemented this, but it turns out to be a bit more complex than I thought, because it is not just a matter of referencing a versioned What I have now is:
Now, we have to decide which of these various files gets committed and which you deploy, and whether or not to rename the files when you deploy them, or just deployed the already-versioned files generated by grunt. |
This is updated based on our discussion. What I have now is:
Can you update the deploy script based on this? |
@paddybyers I have deployed version 0.7.3 of the lib and updated the |
Can you test it and close this once done? |
It doesn't look like it's deploying |
I've raised infrastructure issues for a couple of problems, but this is all working. |
From what I can tell, the iFrame.html and Javascript associated with it is loaded from the REST / Realtime end point such as https://rest.ably.io/static/iframe.html, see https://github.com/ably/ably-js/blob/master/browser/lib/transport/iframetransport.js#L66-L73.
I believe this approach has the following issues:
We should perhaps use Grunt to hard code in a version number based on the git tag and link directly to the cdn.
Note all files needed are on the CDN, see http://cdn.ably.io/lib/iframe.js, http://cdn.ably.io/lib/iframe.min.js and http://cdn.ably.io/lib/iframe.html
The text was updated successfully, but these errors were encountered: