If anyone has an idea to deal with this, please elaborate.
This is why this call only has to be made one time ; the key and secret are then securely persisted into the database and the consumer secret can be ommitted in all subsequent calls. Alternatively, we also provide an API endpoint that you can just curl to provide the consumer key/secret. Our "detailed" documentation (http://js.dotcloud.com/doc.html#c4) is more thorough on that matter.
Hope that answers your question!
Edit: sorry for the late response, happened to be out of town for the last three days. Bad timing. :(
Likewise with user accounts. If they take my keys, and somehow get someones password they'd have the same access they would otherwise have through the GUI. If I put user passwords into the code, well yeah that's totally bad on me.
I don't know. I'm not a security expert, however I've not been able to catch a problem with this. I'd love to know better.
Meteor - http://www.meteor.com/ FireBase - http://www.firebase.com Parse - https://parse.com/docs/js_guide
The later have an easier time integrating into existing client-side frameworks (Backbone, Ember, Angular, etc), since those mostly seem to be built with a REST-based model in mind, but it will be interesting to see what patterns emerge to plug push-based updates into these pull-oriented systems. For starters, I suspect we'll need the client-side frameworks to clarify the distinction between the server and client state and the source of changes. Henrik Joreteg's talk at BackboneConf[1] was good overview of this and other problems they've run into.
[1]: https://speakerdeck.com/u/henrikjoreteg/p/real-world-realtim...
The solution was -- rather than using the video player's API to stop or pause the video -- I had to remove the video entirely from the DOM with Jquery.remove()
plugins set to click to play
