Allow passing headers to the url to pull

[Adrien Lemaire]

Hello,

I would like to pull data from HabitRPG, and it should look like:

curl http://localhost:9999 \
-d column=0 \
-d label="Name" \
-d poll_url="https://habitrpg.com/api/v1/user/tasks?type=habit"  \
-d poll_header="x-api-user: <user-id>" \
-d poll_header="x-api-key: <api-key>" \
-d poll_seconds=10 \
-d poll_failed="Bummer :(" \
-d poll_method="json_value:^.[0].text"

Would it be difficult to implement this new poll_header argument ?

Thanks for considering that feature :)

[Jayme Davis]

Probably not - ill take a look - thanks!

On Apr 14, 2013, at 10:18 PM, Adrien Lemaire [e-mail] wrote:

Hello,

I would like to pull data from HabitRPG, and it should look like:

curl http://localhost:9999
-d column=0
-d label="Name"
-d poll_url="https://habitrpg.com/api/v1/user/tasks?type=habit"
-d poll_header="x-api-user: "
-d poll_header="x-api-key: "
-d poll_seconds=10
-d poll_failed="Bummer :("
-d poll_method="json_value:^.[0].text"
Would it be difficult to implement this new poll_header argument ?

Thanks for considering that feature :)

—
Reply to this email directly or view it on GitHub.

[Rob Scanlon]

I happened to be talking with @Fandekasp about this last night, so I figured I'd take a quick pass at it.

Since hubble is using the request library, one way to accommodate this is to have the user pass something like -d poll_url="{\"uri\":\"https://habitrpg.com/api/v1/user/tasks?type=habit\",\"headers\":{\"x-api-user\":\"<user-id>\",\"x-api-key\":\"<api-key>\"}}" \ and update the code to JSON.parse poll_url into an object if (and only if) its json. Its only a few lines of code because request accepts either a string url or an options object as its first parameter.

The upside to doing it this way is that it is really simple from a code perspective, and you get to pass any option accepted by the request library. The downside is that you tie your implementation closely with request's implementation, and "poll_url" isn't exactly a great description if the user goes with the full json option.

I was hoping you didn't need to change the code at all to have this work, which is why I started going down this path. But turns out you need to add a couple of lines. I'll send a PR with the changes if you are interested in this implementation. I won't be offended if you decide to not go this route -- there are some definite downsides to this approach.

[Rob Scanlon]

Now, having said that @Fandekasp, I"m pretty sure this still won't work with habitrpg because they require your client to accept gzip responses, which the request library doesn't do by default. I'm not sure why this decision was made -- I think its just because the habit API is considered alpha (its secondary to the kickstarter promises) and they haven't spent time making it work uncompressed.

What you need to do is this: http://stackoverflow.com/questions/8880741/node-js-easy-http-requests-with-gzip-deflate-compression

So, that would require adding a little more code here... which is simple enough as a local hack but is not really suitable for inclusion in the main hubble code base (in my opinion).

[Adrien Lemaire]

Right, didn't understand why the curl request wouldn't return results without the --compressed option. Makes sense now :)

[Jayme Davis]

I see what you were tryng to do - clever. :)

I think the original approach is probably a bit more intuitive to use, unless I'm missing something.

[Rob Scanlon]

Yes, the original approach is definitely more intuitive from the user's perspective. And intuitive > clever code just about every time :) Plus, keeping the configuration decoupled from the request library implementation is definitely preferable. I just happened to whip this up in 20 minutes and figured it was worth a PR to illustrate the idea.

Since I'm familiar with the hubble now, I can implement the original method tonight if you don't get around to it...

[Jayme Davis]

Go for it! Thanks for the help. :)

On Apr 16, 2013, at 1:03 PM, Rob Scanlon [e-mail] wrote:

Yes, the original approach is definitely more intuitive from the user's perspective. And intuitive > clever code just about every time :) Plus, keeping the configuration decoupled from the request library implementation is definitely preferable. I just happened to whip this up in 20 minutes and figured it was worth a PR to illustrate the idea.

Since I'm familiar with the hubble now, I can implement the original method tonight if you don't get around to it...

—
Reply to this email directly or view it on GitHub.

[Rob Scanlon]

All set. I'm new to coffeescript, so feel free to suggest any changes that improve the style.