You had me sold at "Consistent parsing of user input between GitHub and the tracker application" Seems like a no-brainer to me considering this is a GitHub app.

+1

It would be ideal as our markup is going to and from github but does this affect to the 5000 request Github limit?

If each parse is a request we can't use it.

The biggest downside I can see so far is the fact that we won't have highlighted code any more :(

I was also thinking about storing the parsed text to the db - who knows how long the comment threads might become..
But if we also want to use the tracker application to create and/or modify issues, we should also store the "raw" text to the db.

The point about the rate limit is also very valid.

But yes, 15k lines of code less to maintain is a good argument.

Theoretically, couldn't we whip up a plugin to do some sort of highlighting
based on markdown? Maybe something like
http://softwaremaniacs.org/playground/showdown-highlight/ or
http://blog.bitbucket.org/2012/02/16/syntax-highlighting-for-markdown-readmes/
?

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Fri, Jan 4, 2013 at 9:49 AM, Nikolai Plath notifications@github.comwrote:

The biggest downside I can see so far is the fact that we won't have
highlighted code any more :(

I was also thinking about storing the parsed text to the db - who knows
how long the comment threads might become..
But if we also want to use the tracker application to create and/or modify
issues, we should also store the "raw" text to the db.

The point about the rate limit is also very valid.

But yes, 15k lines of code less to maintain is a good argument.

—
Reply to this email directly or view it on GitHubhttps://github.com/JTracker/jissues/pull/60#issuecomment-11885088.

@elkuku The lack of code highlighting was one thing I missed doing the conversion. The HTML has a metric crapton of spans and classes on the code, so maybe we need to scrape GitHub's styles to see how they do it? Especially if we're using their markup. The raw text idea is a good idea too, but where would we possibly use this?

As for the rate limit, items will only be parsed in the hooks and preview, which is the only potential place for abuse. User input text should not have to go through the parser when submitted from within the app.

Things to consider:

• What happens if Github is down. If issues are synced we don't require a permanent connection. But parse will require it.
• What happens if Github decides to change the request limit to 1500? Google Maps did it some time ago.

I don't really know how many requests are we going to produce but 5000 doens't seem a too high limit talking globally. Having some real approximation would be great.

That's why the app isn't 100% dependent on GitHub. I'm still not sure whether we should be pushing issues/comments to GitHub from the app when the CMS will still use the app as the single point of truth. So, at worst, we probably get delays in receiving data from GitHub and being unable to parse text through the Markdown parser.

As for the rate limiting, for us to reach 1500 actions in a single hour will probably never happen. I would imagine that at the worst, we've maybe hit 100 in an hour during a coordinated event. If we ever get that high of traffic, I think we deal with it then. Ya, a lot of us hit that limit testing now because we purposely bulk import items. Once live, there will be one bulk and that is it. FWIW, it looks like we can get up to 12500 hits if we register an app to GitHub and send that OAuth key in the requests. See http://developer.github.com/v3/#rate-limiting.

Bottom line, I think we will be OK.

I was wondering about pushing issues/comments to GitHub from the app after
Roberto's comments. What happens if there is a disconnect between the app
and Github? What happens if they get out of sync? For example, someone adds
a comment on an issue via the app, at the same time someone else does via
Github, and the app isn't able to push the comment back to Github for hours
due to network issues?

Am I missing something, and this isn't an issue, or should the app only
pull data?

PS: I'm sure we can clean up the metric crapton of spans and classes on the
code.

Best,

Matt Thomas
Founder betweenbrain http://betweenbrain.com/™
Lead Developer Construct Template Development
Frameworkhttp://construct-framework.com/
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

On Fri, Jan 4, 2013 at 10:24 AM, Michael Babker notifications@github.comwrote:

That's why the app isn't 100% dependent on GitHub. I'm still not sure
whether we should be pushing issues/comments to GitHub from the app when
the CMS will still use the app as the single point of truth. So, at worst,
we probably get delays in receiving data from GitHub and being unable to
parse text through the Markdown parser.

As for the rate limiting, for us to reach 1500 actions in a single hour
will probably never happen. I would imagine that at the worst, we've maybe
hit 100 in an hour during a coordinated event. If we ever get that high of
traffic, I think we deal with it then. Ya, a lot of us hit that limit
testing now because we purposely bulk import items. Once live, there will
be one bulk and that is it. FWIW, it looks like we can get up to 12500 hits
if we register an app to GitHub and send that OAuth key in the requests.
See http://developer.github.com/v3/#rate-limiting.

Bottom line, I think we will be OK.

—
Reply to this email directly or view it on GitHubhttps://github.com/JTracker/jissues/pull/60#issuecomment-11886344.

For the highlighting, GitHub seems to return the code in <code> tags also providing the syntax. I think we might parse this (again) or leave it just red on gray..

The raw text idea is a good idea too, but where would we possibly use this?

I mean if you ever want to edit a comment you would then have to edit the parsed (html) code.

As for the parsing: If I understand correctly, you should be able to create and modify issues and comment on them - is that correct ?

So on creation the description text will be parsed (and if we implement the preview feature on every preview call), and on creating a comment this also must be parsed.
Please correct me..

Maybe we should at least provide some decent "fallback" to a <pre> ;)

And yes, depending on an external service always has downsides.

Um.. @mbabker I didn't read your last comment.
So let's forget about the rate limit for now and see how it works out.
I'm sure we can find a way to color the code somehow - The CSS guys might do something here ;)

Merged - Thanks