Skip to main content
Stack Apps

Return to Question

replaced http://stackapps.com/ with https://stackapps.com/
Source Link
Community Bot
Community Bot
  • 1

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile rather than being blocked by v2 writing (and authentication) features?Could/Should the API evolve more agile rather than being blocked by v2 writing (and authentication) features? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concern, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile rather than being blocked by v2 writing (and authentication) features? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concern, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile rather than being blocked by v2 writing (and authentication) features? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concern, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.

Fixed cross link and typo.
Source Link
Steffen Opel
Steffen Opel
  • 1.4k
  • 8
  • 14

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile/incrementally rather than being blocked with the v2 authentication/write support?Could/Should the API evolve more agile rather than being blocked by v2 writing (and authentication) features? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concernsconcern, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile/incrementally rather than being blocked with the v2 authentication/write support? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concerns, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile rather than being blocked by v2 writing (and authentication) features? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concern, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.

Source Link
Steffen Opel
Steffen Opel
  • 1.4k
  • 8
  • 14

Selective API oriented transcript fragment of Jeffs Code Camp Video Interview.

This is a very selective API oriented transcript fragment of Jeffs Code Camp Video Interview:

Purpose

Please note that this transcript fragment is mainly a supporting post to decrease the length of Could/Should the API evolve more agile/incrementally rather than being blocked with the v2 authentication/write support? and as such only intended as an orientation for those inclined to view the original quote and not necessarily accurate/precise regarding wording/phrasing! Feel free to correct/amend things, but please keep this intention in mind, thanks!

Legend

###Topic: mobile site

  • JA (19:00): I'm kinda torn on this [...] it splits your effort

  • JA (20:04): on Stack Overflow it's not the primary goal to be a mobile site

###Topic: Stack Apps API

  • JA (20:16): [...] read only [...] very hard problem with content coming from an API [...] we are not trying to solve that

  • MH (20:40): Why is that hard, to allow to posting content?

  • JA (20:44): [...] duplicate handling [...] hints [...] none of that would be visible from an API [...] that's probably the main concerns, and then there are rate limiting issues and [...]

  • JA (21:14): Another argument of splitting effort, rather than having content coming in on just one pipe, where we can apply the same rules to, now we have this other pipe [...]

  • MH (21:24): You don't want to take away the value that's part of the UI?

  • JA (21:28): Yeah, the UI is helping [...] there's a lot of ambient information present on the website, how would that even be presented in an external app we can't control? I'm fine with reading [...] but one of the quickest way to ruin a Q&A system is to flood it with bad questions - now I'm not sayin having a write API would cause that, but anything that risks that is a very very serious risk.