The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-1 "['<alt>1']" | |
| gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-2 "['<alt>2']" | |
| gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-3 "['<alt>3']" | |
| gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-4 "['<alt>4']" | |
| gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-1 "['<alt><shift>1']" | |
| gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-2 "['<alt><shift>2']" | |
| gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-3 "['<alt><shift>3']" | |
| gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-4 "['<alt><shift>4']" |
I’m a web app that wants to allow other web apps access to my users’ information, but I want to ensure that the user says it’s ok.
I can’t trust the other web apps, so I must interact with my users directly. I’ll let them know that the other app is trying to get their info, and ask whether they want to grant that permission. Oauth defines a way to initiate that permission verification from the other app’s site so that the user experience is smooth. If the user grants permission, I issue an AuthToken to the other app which it can use to make requests for that user's info.
Oauth2 has nothing to do with encryption -- it relies upon SSL to keep things (like the client app’s shared_secret) secure.
