Add basic Cloud Speech API endpoints

[alexebird]

• also fixed some compilation warnings.

[PhillippOhlandt]

Oh, just what I need. Having this merged, together with a new release would be nice @sashaafm :)

[sashaafm]

Hello @PhillippOhlandt, I'm inclined to add this if the original contributor @alexebird squashes and adds a good commit message.

[PhillippOhlandt]

@sashaafm That sounds like a deal!

[PhillippOhlandt]

I just tested the base branch for this PR. I think it's good to set a very high HTTPoison timeout for the asyncrecognize function. Or better, let the developer pass it as an option.

[PhillippOhlandt]

I just saw, the PR uses the v1beta1 API version. There is an official, slightly different v1 now.
https://cloud.google.com/speech/reference/rest/v1/speech/longrunningrecognize

[alexebird]

I'll get this updated!

…

On Mon, Jun 12, 2017 at 6:43 AM Phillipp Ohlandt ***@***.***> wrote: I just saw, the PR uses the v1beta1 API version. There is an official, slightly different v1 now. https://cloud.google.com/speech/reference/rest/v1/speech/longrunningrecognize — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHXZuuDPe0K7WytfnbEVZzfZYrT2P2zks5sDUCNgaJpZM4MpPpb> .

[PhillippOhlandt]

@alexebird awesome! :)

[alexebird]

@sashaafm @PhillippOhlandt How do the changes look?

[PhillippOhlandt]

@alexebird There is one thing in the example body you have to change. In the v1 API they changed the sampleRate key to sampleRateHertz. Otherwise I think it looks good.

I saw you put a fixed timeout of 50 seconds in the request functions. This works. I hotpatched that in my local version to that value too. I also created #10 to ask if we can make this somehow configurable.

[PhillippOhlandt]

Another thing we could consider is letting the user pass in a map as body instead of raw json. This makes the API for the user a bit cleaner. What do you think?

[alexebird]

Hey @PhillippOhlandt, sorry for the radio silence. I'm hoping to pick up work on my Elixir project again soon and I intend to include this PR in that. I'll look into passing the body as a map, but if it's a large change I don't want to give in to that scope creep.

-bird

[PhillippOhlandt]

@alexebird I could live without the body as map. But the example body should be fixed to not confuse new users.

[PhillippOhlandt]

It would be nice if this PR could be merged or if the new changes from this repo could be added to @alexebird fork. I am currently using this fork and my project is broken on OTP20 because I can't pull in the newest version of json_web_token (garyf/json_web_token_ex#20) due to Poison version conflicts.

[alexebird]

Sorry, I haven’t been working on this project much lately but I will try to get my fork updated shortly.

…

On Wed, Nov 1, 2017 at 4:09 AM Phillipp Ohlandt ***@***.***> wrote: It would be nice if this PR could be merged or if the new changes from this repo could be added to @alexebird <https://github.com/alexebird> fork. I am currently using this fork and my project is broken on OTP20 because I can't pull in the newest version of json_web_token( garyf/json_web_token_ex#20 <garyf/json_web_token_ex#20>) due to Poison version conflicts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHXZgLBQwwDYSElNPXO-91g658c5Aoyks5syFFQgaJpZM4MpPpb> .

[PhillippOhlandt]

@alexebird just the mix.lock has conflicts with the current branch. Shouldn't be that hard to resolve.

[alexebird]

@PhillippOhlandt Got the conflict resolved.

@sashaafm However, I had to bump the Elixir version to 1.4.0 to get the build to pass. I want to get this merged. Is this version bump okay?

[sashaafm]

Yes this is ok

[sashaafm]

If it is ready for merging?

[alexebird]

@sashaafm Merge Away!