WebFund 2013F Lecture 16: Difference between revisions
Created page with "The audio from the lecture given on November 11, 2013 is [http://homeostasis.scs.carleton.ca/~soma/webfund-2013f/lectures/comp2406-2013f-lec16-13Nov2013.m4a here]." |
No edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
The audio from the lecture given on November | The audio from the lecture given on November 13, 2013 is [http://homeostasis.scs.carleton.ca/~soma/webfund-2013f/lectures/comp2406-2013f-lec16-13Nov2013.m4a here]. | ||
==Notes== | |||
* Control flow graph | |||
** graph representation of program structure | |||
** you should know how things move in your program | |||
*** graph is weird for web applications | |||
**** no main => event driven | |||
**** distributed | |||
***** control flow goes between browser and one or more servers | |||
**** RPC (RemoteProcedureCall) | |||
***** sometimes when making a call? Actually making a call on something on the network | |||
***** RPC's have fundamental security problems | |||
***** always call by value (pass number along) | |||
**** SOAP | |||
***** effort to do RPC over the web | |||
***** Problems? | |||
****** Based on XML | |||
******* very verbose | |||
******* SOAP protocols based on XML are VERY verbose | |||
**** REST | |||
***** GET, POST, etc | |||
* Databases | |||
** don't want to store everything just in a text file | |||
*** multiple files is a pain | |||
** associative arrays are easier to get access to | |||
** concurrency | |||
*** I want to change data structures all over the place | |||
**** allow for concurrent updates without corrupting entire thing | |||
** durability | |||
*** can change values incrementally | |||
** We will be using MongoDB | |||
*** “document store” | |||
**** it's like you are storing a collection of word documents | |||
**** allows to to incrementally update parts of the document without corrupting everything | |||
**** transactions | |||
***** making changes to multiple durable data structures | |||
****** changes are always consistent | |||
******* all should happen or none should happen | |||
******* atomic commits | |||
***** documents are basically JSON objects |
Latest revision as of 23:38, 25 November 2013
The audio from the lecture given on November 13, 2013 is here.
Notes
- Control flow graph
- graph representation of program structure
- you should know how things move in your program
- graph is weird for web applications
- no main => event driven
- distributed
- control flow goes between browser and one or more servers
- RPC (RemoteProcedureCall)
- sometimes when making a call? Actually making a call on something on the network
- RPC's have fundamental security problems
- always call by value (pass number along)
- SOAP
- effort to do RPC over the web
- Problems?
- Based on XML
- very verbose
- SOAP protocols based on XML are VERY verbose
- Based on XML
- REST
- GET, POST, etc
- graph is weird for web applications
- Databases
- don't want to store everything just in a text file
- multiple files is a pain
- associative arrays are easier to get access to
- concurrency
- I want to change data structures all over the place
- allow for concurrent updates without corrupting entire thing
- I want to change data structures all over the place
- durability
- can change values incrementally
- We will be using MongoDB
- “document store”
- it's like you are storing a collection of word documents
- allows to to incrementally update parts of the document without corrupting everything
- transactions
- making changes to multiple durable data structures
- changes are always consistent
- all should happen or none should happen
- atomic commits
- changes are always consistent
- documents are basically JSON objects
- making changes to multiple durable data structures
- “document store”
- don't want to store everything just in a text file