opentok / opentok-node Goto Github PK

the current archiving implementation is built as a functional "extension" of the OpenTok object definition. it would be nice to clean this up to make the code less repetitive and harmonious. this also includes the jasmine based tests (which contrast with the other mocha based tests).

it would be favorable to keep the implementation of archiving decoupled. one possible solution is to export a "mix-in" function from lib/archiving.js that could be used to extend OpenTok.prototype.

the Session object should have properties for location and p2p and a generateToken method.

right now, in test/session-test.js, there are plenty of TODOs to check the validity of tokens that are generated. these duplicate the existing tests for token validity in test/opentok-test.js. ideally, both those files should use a common implementation to test the interface since so much of them are the same.

find a suitable mocking solution so that network calls don't actually go over the network. this may be intertwined with adding a dependency injection interface into the OpenTokSDK constructor.

• Install:
• Install using npm
• Download manually (using GitHub releases)
• Usage:
• Initializing
• Creating Sessions
• Generating Tokens
• Working with Archives
• Documentation
• Requirements
• Changes / Release Notes
• Contributing / Testing

This issue is related to #75 and #73.

In addition to allowing a Date object to be given as the expireTime, it also makes sense to solve the common issue of a fractional number being specified by just automatically rounding the number to a whole number.

http://docs.travis-ci.com/user/languages/javascript-with-nodejs/

https://coveralls.io/docs/node

already done, but once branch is merged to master, its got to be forced.

Works

token = opentok.generateToken( myToken, {
  role: 'moderator'
});

Broken

token = opentok.generateToken( myToken, {
  role: 'moderator',
  expireTime: (new Date().getTime() / 1000)+(7 * 24 * 60 * 60)
});

It seems to not be a loud enough signal to return an Error object when the OpenTok constructor fails. this occurs when the apiKey or apiSecret arguments are invalid. A louder signal would be to throw the Error, and that seems to be the best practice recommendation.

In the PHP SDK, we are using JSON Schema to validate what comes back from the server. This would be a nice catch for a Response Error where the version of the SDK is outdated against the API.

Ideally, I would love to send my credentials to check they're also still valid, but I would accommodate just a ping that tells me your service is working well.

There needs to be a set of Error types defined and their meaning nailed down so that developers can predictably deal with error conditions.

This will also be subject to an internal API Review.

related to #38

try to get the generated version number into the format PACKAGE_NAME\VERSION

According to documentation: "The location setting is optional, and generally you should not include it. "
http://www.tokbox.com/opentok/api/tools/documentation/api/rest_api.html

Ideas:

• update version strings (or check that they match)
• make new commit, tag, push
• shrinkwrap the module and upload it to GitHub Releases
• upload to npm

Calling session.generateToken() produces the following error:

Uncaught TypeError: Object #<Object> has no method 'generateToken'

nock, the http intercepting module used, has a new feature called nock back (https://github.com/pgte/nock#nock-back). it can be used to get the fixtures of requests/replies out of the test code and into a declarative json file. this would make things much cleaner.

timeout is a useful option to configure the http layer.

The currently released version on npm.js is 0.3.4 which is too old. It's also referencing the bsstoner/opentok repository.

Would it be possible to release it with the 1.0.1 version?
Thanks!

Dear Opentok Support,

I am currently investigating Opentok and its API. Have noticed, that in _doRequest() function you use global variables "options" and "req". It breaks the application built on Express, req is always empty after I request an opentok session (call _doRequest). Please, make them private variables, it is easy and won't affect the code flow, but will enhance the stability and compatibility.

Thanks!

returning null assumes that a developer will be checking the return value, which almost never happens in the javascript ecosystem. this type of a mistake is one that is usually encountered in development (the wrong parameters are passed to the method), therefore its reasonable to blow up by throwing an Error.

sometimes just checking against canned responses (fixtures) is not good enough.

the main use case for integration testing is running the suite against the internal nightly build environment to detect problems (incompatible API changes, bad handling in the SDKs, etc) early.

one of the challenges in running integration tests is that many of the operations being tested require a specific state on the server. for example: starting an archive successfully requires that at least one client connection to the specific OpenTok session exists, deleting an archive requires an archive to exist, stopping an archive requires a started archive, etc.

one approach is being explored in #65. this approach attempts to repurpose the unit tests to run in a different mode where they can hit live servers.

another approach could be scenario-driven, where a scripted set of operations are carried out sequentially. this could be better in address the challenge with server side state.

another technique that could be employed to address the server side state challenge is using a specific build of the client side opentok.js library that can run in node. the integration tests could "shell out" to a CLI that can conduct client side operations that will assist in setting up the proper state (like a client connection before starting an archive).

it is useful in scenarios where the apiUrl is optionally set, and the consumer needs to use the URL somewhere else in their code.

link to generated docs in README.md

2787 error Valid install targets:
2787 error ["0.10.0","0.8.3","0.9.0","0.9.1","0.9.5","1.0.0","1.1.0","1.1.1","1.2.0","1.9.0","1.9.1","1.9.2","1.9.3","1.9.5","1.9.7","1.9.8","1.9.9","2.0.0","2.0.1","2.0.
2787 error at installTargetsError (/tmp/build_5556f456-e0fe-43e4-8a0e-fb380ad7bac7/vendor/node/lib/node_modules/npm/lib/cache.js:685:10)
2787 error at /tmp/build_5556f456-e0fe-43e4-8a0e-fb380ad7bac7/vendor/node/lib/node_modules/npm/lib/cache.js:607:10
2787 error at saved (/tmp/build_5556f456-e0fe-43e4-8a0e-fb380ad7bac7/vendor/node/lib/node_modules/npm/node_modules/npm-registry-client/lib/get.js:138:7)
2787 error at Object.oncomplete (fs.js:107:15)
2788 error If you need help, you may report this log at:
2788 error http://github.com/isaacs/npm/issues
2788 error or email it to:
2788 error [email protected]
2789 error System Linux 3.8.11-ec2
2790 error command "/tmp/build_5556f456-e0fe-43e4-8a0e-fb380ad7bac7/vendor/node/bin/node" "/tmp/build_5556f456-e0fe-43e4-8a0e-fb380ad7bac7/vendor/node/bin/npm" "install"
2791 error cwd /tmp/build_5556f456-e0fe-43e4-8a0e-fb380ad7bac7
2792 error node -v v0.10.4
2793 error npm -v 1.2.18
2794 verbose exit [ 1, true ]

! Push rejected, failed to compile Node.js app

To [email protected]:office-hours-testing.git
! [remote rejected] development-bit -> master (pre-receive hook declined)

the current problem with the tests is that they look no different from the tests that don't use a proxy. hence there is no way to verify that the proxy is actually working, we only know that we didn't break the request by setting the proxy configuration.

it exists in the REST API. does anyone have a need for it in the SDK?

Using this api and passing the options { mediaMode : "routed" } doesn't actually seem to created a routed connection. When I connect iOS clients they can't publish to more than one subscriber.... however, if I hard code tokens and session ids generated by the online dashboard for OpenTok, everything works perfectly.

I'm now going to implement a version of my own using the OpenTok REST api and the "https" request module to see if this avoids the issue.

Most Readme links in documentation point to pages on tokbox that no longer exist.

Currently the expireTime option expects a unix timestamp in seconds. This means that every user would have to understand how to convert a Date object into a unix timestamp in seconds properly. I don't see any way to get this value without first going through a Date object. That conversion can be error-prone for users (see #71). This proposal is to make the API backwards compatible and accept Number | Date types.

Clicking http://tokbox.com/opentok/libraries/server/node/reference/index.html sends me to a 404.