Implement Gist onebox


(Sam Saffron) #1

We had a naive implementation for Gist oneboxes, however it failed miserably due to dynamic loading:

In particular this:

To resolve this issue:

The Gist oneboxer should use a similar approach to the blob oneboxer

  1. It must take care of truncating huge files
  2. It must take care of displaying gists with multiple files

Syntax highlighting is to be handled by our pre-existing syntax highlighting engine, all the onebox is to do is to decorate divs with the guessed syntax.

I thought of possibly using therubyracer to evaluate the gist js, but it inserts stylesheets. Additionally there is a possibly iframe approach but it will be both slower (and impact rendering) and more fragile.

Will Discourse apply for Google Summer of Code 2015?
(Guilherme Carreiro) #2

I’m working on it.

It’s relevant, right?
(I’m asking because is an “old topic” rs)


(Guilherme Carreiro) #3


I was following a similar approach to the blob oneboxer, that is to make requests to “Gist API” and build a HTML component on server side. It sounded clean for me.

However, I’m concerned about something that read here (GitHub API v3 | GitHub Developer Guide):
“For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour.”

I think that is a bad idea to make requests to Gist API from server side, considering that low limit. So, what do you think about to make these requests from the client side

Some JavaScript would be added in the mustache templete to keep the component decoupled.


(Dave McClure) #4

I think the onebox content is all baked into the cooked HTML, which means that the server only needs to hit the Gist API once for any given link.

(Guilherme Carreiro) #5

Hmm… I don’t think so…

The flow that I’m thinking is:

  1. The “Gist URL” is detected in the message:

  2. We detect the URL and the sha: 208fdd59fc4b4c39283b

  3. We make a request to “Gist API” to obtain the information:

Finally, we manipulate the JSON response to cook the HTML through a mustache template, that would be something like this:

  <a href="{{link}}" target="_blank">{{title}}</a>
      <code class='{{language}}'>
        This file has been truncated. <a href="{{link}}" target="_blank">show original</a>

So, every time that we detect a Gist URL, we’ll need to make a different request to “Gist API” to obtain specific information.

Am I right? .-.

Thanks! :slight_smile:

(Sam Saffron) #6

Correct, so a condition where users on your site are posting more than 60 gists per hour in posts would be … presumably … quite rare.

Also … we are open to a PR that wires in GitHub OAuth stuff if you really want it.

(Guilherme Carreiro) #7

Ohh! Now I realised what @mcwumbly said!

Thank you guys.

I’ll keep the server side approach, without the OAuth implementation, for while.

Thanks again. :wink:

(Guilherme Carreiro) #8

(Ahmad Mushtaq) #9

Can we now mark this as closed/implemented?

(Sam Saffron) #10


(Jeff Atwood) #11

I guess it is working now! :partly_sunny:

(Jeff Atwood) #12