Conversation
|
Not sure how this facilitates development, rather encourages incorrect behavior I would think. This capability was specifically removed a few commits ago in favor of an automatic (and preferred) method. |
| client.open({ | ||
| authToken: process.argv[2], | ||
| versionId: parseInt(process.argv[3], 10), | ||
| url: process.argv[4] || null, |
There was a problem hiding this comment.
I'd rather not push 'weirdness' to a public example for functionality that's only useful for internal testing.
|
Ahh we nuked this when i added endpoint discovery. Yeah it shouldn't be in the examples in our master branch |
| return super.open({ | ||
| authToken: options.authToken, | ||
| url: endpoints[0].address, | ||
| url: options.url || endpoints[0].address, |
There was a problem hiding this comment.
We should probably avoid the external HTTP call here.
if(options.url) { proimse.resolve().then(....)
maybe?
There was a problem hiding this comment.
Well, actually. Running the standalone service it exposes a "fake" discovery endpoint which discovers itself. So alternately the option could be passed as an API base URL, which could be reused later if, for example, shortcode OAuth support is integrated into the library. (The standalone tetrisd service also exposes fake shortcode endpoints)
|
@kateract specifically. Internal beam developers can run a copy of our interactive service locally. This would be a 122.0.0.1 address. This let's developers connect to those local copies. |
|
@ProbablePrime sorry, I didn't realize he was on your team, but the internal wording makes more sense now. |
|
@saadataz I'll take over ownership of this and get it done, I'm more familiar with the requirements thanks! |
|
I am now closing this as its goals are covered in #69 |
4 participants
To facilitate development, allow specifying server URL in basic example