<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: mobapp-spring10.xml 1393 2010-09-15 23:52:15Z dret $ -->
<?hotspot layout-path="hotspot/hotspot/layout" ?>
<?hotspot kilauea-path="hotspot/kilauea" ?>
<?hotspot layout="ischool" ?>
<hotspot xmlns="http://dret.net/xmlns/hotspot/1" xmlns:hotspot="http://dret.net/xmlns/hotspot/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://dret.net/xmlns/hotspot/1  hotspot/hotspot/schemas/hotspot.xsd">
	<configuration>
		<link subsections="yes" bookmarks="yes" versions="web-spring10.xml" home="./" help="quick" contents="./" glossary="http://dret.net/glossary/" author="http://dret.net/netdret/"/>
		<paths img="img" listing="src"/>
		<outline count-text=" [*]" count-depth="all"/>
		<hyperlink extra=""/>
		<extension file="html" link=""/>
		<counter separator=":&#160;"/>
	</configuration>
	<license uri="http://creativecommons.org/licenses/by/3.0/" short="CC 3.0">
		<div class="license">
			<p><a rel="license" title="view full text of license" href="http://creativecommons.org/licenses/by/3.0/"><img alt="Creative Commons License" src="hotspot/hotspot/layout/ischool/ischool/somerights20.png" border="0" height="31" width="88"/></a></p>
			<p><a class="outlink" rel="license" title="view full text of license" href="http://creativecommons.org/licenses/by/3.0/">This work is licensed under a CC<br/>Attribution 3.0 Unported License</a></p>
		</div>
	</license>
	<title short="Mobile Application Design and Development"><a href="./" title="Course Homepage">Mobile Application Design and Development</a><br/>Spring 2010 &#x2014; INFO 152 (CCN 42504)</title>
	<author affiliation="UC Berkeley ISchool"><a href="http://dret.net/netdret/" title="dret.net">Erik Wilde</a></author>
	<affiliation short="UC Berkeley ISchool"><a href="http://www.berkeley.edu/" title="University of California, Berkeley">UC Berkeley</a> <a href="http://ischool.berkeley.edu/" title="ISchool">School of Information</a></affiliation>
	<date short="Spring 2010">Spring Semester 2010</date>
	<copyright>2010 Erik Wilde</copyright>
	<categories>
		<category element="xml" class="xml" name="XML"/>
		<category element="elem" class="xml elem" name="XML Element"/>
		<category element="html" class="html" name="HTML"/>
		<category element="htmla" class="html" name="HTML Attribute"/>
		<category element="htmel" class="html elem" name="HTML Element"/>
		<category element="cssp" class="css" name="CSS Property"/>
		<category element="csss" class="css" name="CSS Selector"/>
		<category element="css" class="css" name="CSS"/>
		<category element="xpathf" class="xpath" name="XPath Function"/>
		<category element="xpath" class="xpath" name="XPath"/>
		<category element="xslte" class="xslt elem" name="XSLT Element"/>
		<category element="xslta" class="xslt" name="XSLT Attribute"/>
		<category element="xslt" class="xslt" name="XSLT"/>
		<category element="xsde" class="xsd elem" name="XSD Element"/>
		<category element="xsda" class="xsd" name="XSD Attribute"/>
		<category element="xsd" class="xsd" name="XSD"/>
		<category element="uri" class="uri" name="URI"/>
		<category element="http" class="http" name="HTTP"/>
		<category element="mime" class="mime" name="MIME"/>
		<category element="atom" class="atom" name="Atom"/>
	</categories>
	<toc name="toc.html">
		<table xmlns="" rules="all" cellspacing="0" cellpadding="5" width="100%">
		<!-- xmlns="" makes sure the document can be included into a web page setting xmlns to the HTML namespace. -->
			<thead>
				<tr>
					<th valign="bottom">Date</th>
					<th valign="bottom">Subject</th>
					<th valign="bottom">Slides</th>
					<th valign="bottom">Required Reading</th>
					<th valign="bottom">Additional Resources</th>
					<th valign="bottom">Assignments</th>
				</tr>
			</thead>
			<tbody>
				<hotspot:for-each-presentation>
					<tr>
						<td align="right" valign="top"><hotspot:date/></td>
						<td valign="top">
							<hotspot:if-toc class="author">
								<span class="guest"><hotspot:toc class="author"/> : </span>
							</hotspot:if-toc>
							<b><hotspot:title/><span class="toggle"> &#8212; </span></b> <span class="toggle"><span class="abstract"><hotspot:toc class="abstract"/></span></span></td>
						<td align="center"><hotspot:presentation-link title="Lecture Slides"><hotspot:title form="short"/></hotspot:presentation-link></td>
						<td align="center"><hotspot:toc class="reading"/></td>
						<td align="center"><hotspot:toc class="resources"/></td>
						<td align="center"><hotspot:toc class="assignment"/></td>
					</tr>
				</hotspot:for-each-presentation>
			</tbody>
		</table>
	</toc>
	<presentation id="intro">
		<title short="Introduction">Overview and Introduction</title>
		<date>2010-01-20</date>
		<toc class="resources"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd" title='bSpace "MobApp Spring 2010" site'>bSpace Site</a></toc>
		<toc class="abstract">This introductory lecture covers organizational issues of the <q>Mobile Application Design and Development</q> course. We will discuss the course topics and the syllabus, the assignments and what we expect in terms of prerequisites and how assignments will be supported, and some administrative issues.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="syllabus">
			<title>Syllabus</title>
			<slide>
				<title>Topics Covered</title>
				<ul>
					<li><link href="landscape">Landscape</link>, <link href="history">history</link>, and mobile application use cases</li>
					<li>Application technology (Web-based apps vs. run-time environments vs. native apps)</li>
					<li>Application technology (Web-based apps vs. run-time environments vs. native apps)</li>
					<li>Content technology (HTML, CSS, scripting, Ajax, frameworks, …)</li>
					<li>Content delivery (HTTP, XML, JSON, CDN, …)</li>
					<li>Content management and services (feeds, authentication, queries, …)</li>
					<li>User experience and interface design (mobile-specific issues)</li>
				</ul>
			</slide>
		</part>
		<part id="assignments">
			<title>Assignments</title>
			<slide>
				<title>Focus on Web-Based Applications</title>
				<ul>
					<li>Device-independent (well, almost …)</li>
					<li>Easier to get started</li>
					<li>Easier for a diverse set of developers</li>
				</ul>
			</slide>
			<slide>
				<title>Assignment 1: Setup</title>
				<ul>
					<li>Install local browsers (Fennec, Safari)</li>
					<li><q>Configure</q> access to Web-based browser emulator (Opera mini)</li>
					<li>Install local device/browser emulator (Android)</li>
					<li>Setup account and Web space for serving Web content</li>
				</ul>
			</slide>
			<slide>
				<title>Assignment 2: jQuery</title>
				<ul>
					<li><a href="http://jquery.com/">jQuery</a> is a JavaScript framework for Web page development</li>
					<li>JavaScript frameworks have two major purposes:</li>
					<ol>
						<li>make Web development easier (support popular design patterns)</li>
						<li>make Web pages more robust (deal with issues caused by browsers)</li>
					</ol>
					<li>Use two popular data sources for Web pages:</li>
					<ol>
						<li><em>flickr</em> as a popular photo-sharing service (allows geo-coding photos)</li>
						<li><em>twitter</em> as a popular microblogging service (allows geo-coding updates)</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Assignment 3: jQTouch</title>
				<ul>
					<li><a href="http://www.jqtouch.com/">jQTouch</a> is a jQuery plugin for iPhone/iPod look&amp;feel</li>
					<li>Turns Web-based applications into device-specific applications</li>
					<li>Native look&amp;feel but much cheaper/faster to develop</li>
				</ul>
			</slide>
			<slide>
				<title>Assignment 4: Map-Based Data</title>
				<ul>
					<li>Location-based services are a popular use case for mobile applications</li>
					<li>Use map-based display for flicks and twitter data</li>
					<li>Map-based display always is a <q>mashup</q> between data sources</li>
					<ul>
						<li>the map service serving the map tiles</li>
						<li>the data service serving data that is put on the map</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Assignment 5: mobileOK Content</title>
				<ul>
					<li>Many mobile browsers are not as powerful as desktop browsers</li>
					<li><q>mobileOK</q> is a test suite for testing for compatibility with basic browsers</li>
					<ul>
						<li>small screen, small memory, no scripting, …</li>
					</ul>
					<li>mobileOK sites typically have reduced functionality</li>
					<ul>
						<li>even map-based display is possible with server-generated images</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Assignment 6: Server Configuration</title>
				<ul>
					<li>Mobile devices come in many shapes and sizes</li>
					<li>Wider variability of devices/browser means <q>one size does not fit all</q></li>
					<li>Servers can deliver content based on incoming requests</li>
				</ul>
			</slide>
			<slide>
				<title>Assignment 7: Performance Analysis</title>
				<ul>
					<li>Bandwidth still is a critical resource</li>
					<li>Many Web pages today are very resource-intensive</li>
					<ul>
						<li>Web pages need many Web resources (images, …) to be rendered</li>
						<li>Web pages need many network resources (bandwidth, …) to be rendered</li>
						<li>Web pages need many local resources (local memory, …) to be rendered</li>
					</ul>
					<li>Performance analysis for mobile Web pages is essential</li>
				</ul>
			</slide>
			<slide>
				<title>Assignment 8: Server-Side Programming</title>
				<ul>
					<li>Client-side functionality is limited by several factors</li>
					<li>Outsourcing functionality to the server can save resources</li>
					<ul>
						<li>Web development in recent years has done the opposite</li>
					</ul>
					<li>Server-side functionality can be reused across applications</li>
					<ul>
						<li>can be used by different version of Web applications</li>
						<li>can be used by native applications</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Assignment 9: UI Design</title>
				<ul>
					<li>Mobile settings have specific requirements</li>
					<ul>
						<li>more constrained environment in a variety of ways</li>
						<li>more task-oriented users</li>
					</ul>
					<li>Designing mobile applications may change applications pretty radically</li>
					<ul>
						<li>more limited functionality of applications/services</li>
						<li>maybe even different applications depending on the task/role</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Final Project</title>
				<ul>
					<li>Use the skills learned in all assignments</li>
					<li>Design and build a mobile app for managing geospatial information</li>
					<li>Two full weeks for design and implementation issues</li>
				</ul>
			</slide>
		</part>
		<part id="admin">
			<title>Administration</title>
			<slide>
				<title>Course Times</title>
				<ul>
					<li>Meeting times Mon/Wed/Fri 13.00-14.00</li>
					<ul>
						<li>Mondays typically lectures on concepts and background information</li>
						<li>Wednesdays typically lectures on technologies and applied concepts</li>
						<li>Fridays practical issues, demos, experiments, lab time</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Grading</title>
				<ul>
					<li>Class participation: 10%</li>
					<li>Assignments: 60%</li>
					<ul>
						<li>all assignments must be turned in on time</li>
						<li>all assignments must be graded at least as satisfactory</li>
					</ul>
					<li>Final Project: 30%</li>
					<ul>
						<li>the final project must be turned in on time</li>
						<li>the final project must be graded at least as satisfactory</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>About Me</title>
				<ul>
					<li>Computer Science at <a href="http://www.tu-berlin.de/eng/">Technical University of Berlin (TUB)</a> (88-91)</li>
					<li>Ph.D. at <a href="http://www.ethz.ch/index_EN">ETH Zürich</a> (92-97)</li>
					<li>Post-Doc at <a href="http://www.icsi.berkeley.edu/" title="International Computer Science Institute">ICSI, Berkeley</a> (97/98)</li>
					<ul>
						<li>book on <q><a href="http://dret.net/netdret/publications#wil98">Technical Foundations of the World Wide Web</a></q></li>
					</ul>
					<li>Various activities in Switzerland (98-06)</li>
					<ul>
						<li>teaching at <a href="http://www.ethz.ch/index_EN">ETH Zürich</a> and <a href="http://www.fhnw.ch/">FHNW</a></li>
						<li>working as independent consultant (training, courses, consulting)</li>
						<li>research in <a href="http://dret.net/projects/">various XML-related areas</a></li>
					</ul>
					<li>Professor at the <a href="http://ischool.berkeley.edu/">School of Information</a> (since Fall 2006)</li>
					<ul>
						<li>Technical Director of the <a href="http://isd.ischool.berkeley.edu/">Information and Service Design (ISD) program</a></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>About this Course</title>
				<ul>
					<li>Course Web page: <code><a href="./">http://dret.net/lectures/mobapp-spring10/</a></code></li>
					<li>Course mailing list: <code><a href="mailto:mobapp-spring10@bspace.berkeley.edu">mobapp-spring10@bspace.berkeley.edu</a></code></li>
					<ul>
						<li>archived in the <a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/46cd6a1c-0abf-4e7a-9f2c-6243fa1944ed">bSpace email archive</a></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>About these Slides</title>
				<ul>
					<li>Generated from <a href="http://dret.net/projects/xslidy/">Hotspot</a> <a href="mobapp-spring10.xml">XML</a></li>
					<li>Designed for online presentation and use (lots of links!)</li>
					<ul>
						<li>Firefox <a href="http://dret.typepad.com/dretblog/2008/07/go-up.html">Go Up</a> allows easy navigation up one level</li>
						<li>Firefox <a href="https://addons.mozilla.org/en-US/firefox/addon/1949">Site Navigation Bar</a> supports navigation of links</li>
						<li>Firefox <a href="https://addons.mozilla.org/en-US/firefox/addon/2933">Link Widgets</a> requires a bit more configuration (more flexibility)</li>
						<li>for printing, use <q>a</q> (all slides), and then <q>s</q> (smaller font) a couple of times</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="landscape">
		<title short="Landscape">Mobile Applications Landscape</title>
		<date>2010-01-22</date>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/the_mobile_ecosystem" title="Mobile Design and Development; Chapter 2: The Mobile Ecosystem">Mobile Ecosystem</a></toc>
		<toc class="resources"><a href="http://en.wikipedia.org/wiki/Mobile_device" title="Wikipedia Entry: Mobile Device">Wikipedia:&#160;Mobile&#160;Device</a>&#160;· <a href="http://en.wikipedia.org/wiki/Mobile_Web" title="Wikipedia Entry: Mobile Web">Wikipedia:&#160;Mobile&#160;Web</a>&#160;· <a href="http://en.wikipedia.org/wiki/Mobile_browser" title="Wikipedia Entry: Mobile Browser">Wikipedia:&#160;Mobile&#160;Browser</a></toc>
		<toc class="abstract"><em>Mobile Applications</em> can be defined and approached in a variety of ways. In this lecture, we look at the landscape of mobile applications and the various facets that are relevant for them. This is mostly an overview of the landscape of mobile applications and the factors that are important for that landscape. Specifically, this lecture discusses <em>settings</em>, <em>users</em>, <em>devices</em>, <em>content</em>, and <em>transport</em> issues and how these factor into the design and development of mobile applications.</toc>
		<slide>
			<p class="abstract"><toc class="abstract"/></p>
			<title>Abstract</title>
		</slide>
		<part id="settings">
			<title>Settings</title>
			<slide>
				<title>What does <q>Mobile</q> mean?</title>
				<ul>
					<li>Laptops are <q>mobile devices</q></li>
					<ul>
						<li>in fact, any non-mainframe computer is a mobile device</li>
						<li>laptops are a popular point in a design continuum</li>
					</ul>
					<li><q>Mobile</q> is better defined by <em>settings</em> than by <em>devices</em></li>
					<li><q>Mobile settings</q> can be defined by various properties</li>
					<ul>
						<li>usage of a device with constrained capabilities</li>
						<li>more task-oriented than exploration</li>
						<li>location in many cases is a relevant factor</li>
						<li>circumstances allow less focus on interaction and presentation</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Mobile Computers</title>
				<img src="mobile-computers.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/bigcrow/3070277587/"/>
			</slide>
			<slide>
				<title>Outdoor Offline Users</title>
				<img src="outdoor-offline.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/bugeaters/2328465954/"/>
			</slide>
			<slide>
				<title>Social Connections</title>
				<img src="social-connections.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/lodri/160486209/"/>
			</slide>
			<slide>
				<title>Location Search</title>
				<img src="pizza-sign.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/russelldavies/382320738/"/>
			</slide>
			<slide>
				<title>Mobile Guidance</title>
				<img src="car-navigation.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/sriram/2061177646/"/>
			</slide>
			<slide>
				<title>Mobile E-Books</title>
				<img src="ebook-reader.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/yourdon/3870609298/"/>
			</slide>
			<slide>
				<title>Producers vs. Consumers</title>
				<ul>
					<li><q>Mobile</q> does not specify what the mobile part is</li>
					<ul>
						<li>the service may provide access to information with a <q>mobile</q> component</li>
						<li>the service may be consumed in mobile settings</li>
						<li>in many cases, both of these issues are combined</li>
					</ul>
					<li><q>Mobile Producers</q> require the service to provide location-based information</li>
					<ul>
						<li>clients/users must be able to request information based on location</li>
						<li>the protocol for accessing the service contains location concepts</li>
						<li>it may be irrelevant for the service where the client is located</li>
					</ul>
					<li><q>Mobile Consumers</q> are accessing services/data from mobile settings</li>
					<ul>
						<li>clients/users may have a way to determine their location</li>
						<li>data can be stored locally or accessed over a network</li>
						<li>location of the client/user is an important parameter</li>
					</ul>
					<li>All these issues can become complicated and distributed across services</li>
					<ol>
						<li>use a camera to take pictures on a trip (tagged with timestamps)</li>
						<li>carry a GPS receiver to create a time-coded GPS track</li>
						<li>process the pictures to add location tags based on their timestamps</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Producing Mobile Data</title>
				<table width="95%">
					<tr>
						<td>
							<iframe width="500" height="600" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="http://maps.google.com/maps?f=q&amp;source=s_q&amp;hl=en&amp;geocode=&amp;q=http:%2F%2Fdret.net%2Flectures%2Fmobapp-spring10%2Fsrc%2Ffiretrail.gpx&amp;sll=37.875733,-122.265092&amp;sspn=0.015582,0.02311&amp;ie=UTF8&amp;t=p&amp;ll=37.87526,-122.243843&amp;spn=0.04065,0.042915&amp;z=14&amp;output=embed"></iframe><br /><small><a href="http://maps.google.com/maps?f=q&amp;source=embed&amp;hl=en&amp;geocode=&amp;q=http:%2F%2Fdret.net%2Flectures%2Fmobapp-spring10%2Fsrc%2Ffiretrail.gpx&amp;sll=37.875733,-122.265092&amp;sspn=0.015582,0.02311&amp;ie=UTF8&amp;t=p&amp;ll=37.87526,-122.243843&amp;spn=0.04065,0.042915&amp;z=14" style="color:#0000FF;text-align:left">View Larger Map</a></small>
						</td>
						<td>
							<img style="width : 50% ; margin : 10% ; " src="310xt.jpg" title="GPS"/>
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>Consuming Mobile Data</title>
					<img src="berkeley-panoramio.png" style="width : 90% ; margin : 2em ; " href="http://maps.google.com/?ie=UTF8&amp;hq=&amp;hnear=Berkeley,+Alameda,+California+94720&amp;lci=com.panoramio.all&amp;ll=37.871805,-122.259099&amp;spn=0.031099,0.05373&amp;t=p&amp;z=15"/>
			</slide>
		</part>
		<part id="users">
			<title>Users</title>
			<slide>
				<title>Professional Users</title>
				<ul>
					<li>Exclusively task-oriented</li>
					<li>Regulatory and legislative side-effects</li>
					<ul>
						<li>any medical application must be very secure (patient privacy)</li>
						<li>sometimes it may be necessary to be able to trace everything (audits)</li>
					</ul>
					<li>Device landscapes can be managed top-down</li>
					<ul>
						<li>Blackberry's are not especially good, but very convenient for centralized IT</li>
						<li><q href="http://en.wikipedia.org/wiki/Vendor_lock-in">lock-in</q> often has short-time savings and long-term costs</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Social Users</title>
				<ul>
					<li>Goal-oriented instead of task-oriented</li>
					<li>Choice of technology or channel is opportunistic</li>
					<li>Technology must be simple to use and convenient</li>
					<ul>
						<li>little need for latest technologies or devices</li>
					</ul>
					<li>Cost often is an important issue</li>
				</ul>
			</slide>
			<slide>
				<title>Exploring Users</title>
				<ul>
					<li>No specific goal or task orientation</li>
					<li><q>Technology use</q> as entertainment</li>
					<ul>
						<li>technology itself is used as entertainment</li>
					</ul>
					<li>Typically less cost-sensitive than social users</li>
				</ul>
			</slide>
		</part>
		<part id="devices">
			<title>Devices</title>
			<slide>
				<title>Device Differences</title>
				<ul>
					<li>Screen size (15" to 1")</li>
					<li>Screen technology (color or monochrome, LCD or e-ink)</li>
					<li>Keyboard input (regular, virtual, numbers only, T9)</li>
					<li>Pointing device (none, mouse, trackball, touchscreen)</li>
					<li>Device functions (video, audio, phone, Wi-Fi)</li>
					<li>Internal environment (OS, runtime environment, APIs, content formats)</li>
				</ul>
			</slide>
			<slide>
				<title>Mobile Computers</title>
				<img src="laptop.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/goobi/4021009835/"/>
			</slide>
			<slide>
				<title>Smartphones</title>
				<img src="smartphone.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/lenovophotolibrary/4266088664/"/>
			</slide>
			<slide>
				<title>Dedicated Devices</title>
				<img src="e-book.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/ceslava/3458456577/"/>
			</slide>
			<slide>
				<title>Pervasive Computing</title>
				<img src="road-pricing.jpg" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/File:ERPBugis.JPG"/>
			</slide>
		</part>
		<part id="content">
			<title>Content</title>
			<slide id="web-based">
				<title>Web-Based Applications</title>
				<ul>
					<li>Server-side applications serve Web pages</li>
					<li>Client-side browsers let the user navigate pages</li>
					<li>More diversity than in the pre-mobile age</li>
					<ul>
						<li>Devices and platforms and browsers are more diverse</li>
					</ul>
					<li>Easiest way to make content available to users worldwide</li>
					<ul>
						<li>limitations based on HTML/CSS/scripting and the local platform</li>
						<li>HTML5 and more powerful devices are narrowing the gap</li>
					</ul>
				</ul>
			</slide>
			<slide id="runtime">
				<title>Runtime Environments</title>
				<ul>
					<li>Virtual machines as hardware abstraction</li>
					<li>Decoupling between concrete OS and application runtime environment</li>
					<li>Building a complete and good virtual platforms is hard</li>
					<ul>
						<li>performance can be problematic (optimization possible but hard)</li>
						<li>security is a big problem (a complete new set of attack points)</li>
					</ul>
					<li>Interesting as a hybrid approach between Web and native</li>
				</ul>
			</slide>
			<slide id="native">
				<title>Native Applications</title>
				<ul>
					<li>Built specifically for one platform (OS plus runtime environment)</li>
					<li>Allows the highest degree of sophistication</li>
					<ul>
						<li>access to all capabilities of the platform</li>
					</ul>
					<li>Requires the highest degree of developer sophistication</li>
					<ul>
						<li>programming often requires a complex non-scripting language</li>
						<li>the programming environment is complex and hard to learn</li>
					</ul>
					<li>Economically only feasible for popular platforms</li>
				</ul>
			</slide>
		</part>
		<part id="transport">
			<title>Transport</title>
			<slide>
				<title>Connecting Clients and Servers</title>
				<ul>
					<li>Worldwide there are two dominant information networks</li>
					<ul>
						<li>the worldwide phone network</li>
						<li>the Internet</li>
					</ul>
					<li>Connections change over time</li>
					<ul>
						<li>for a long time there only was the postal service</li>
						<li>telegraph services were the first global immediate services</li>
					</ul>
				</ul>
			</slide>
			<part id="transport-phone">
				<title>Phone Transport</title>
				<slide id="fax">
					<title>Fax</title>
					<ul>
						<li><a href="http://en.wikipedia.org/wiki/Fax">Telefax</a> has been around for a long time</li>
						<ul>
							<li>the <q>service</q> in immediate scan/print to a phone endpoint</li>
							<li>all of that service can be easily replicated differently</li>
							<li>fax machines are still used and sold mostly for convenience</li>
						</ul>
						<li>Fax was the first major non-speech usage of the phone network</li>
						<ul>
							<li>Internet access started as over-the-phone but outgrew phone line capacities</li>
						</ul>
					</ul>
				</slide>
				<slide id="messaging">
					<title>Messaging</title>
					<ul>
						<li>SMS (<q>texting</q>) started in GSM countries</li>
						<ul>
							<li>CDMA initially did not have texting capabilities</li>
						</ul>
						<li>SMS is one of the most interesting <q>reappropriation stories</q></li>
						<ul>
							<li>it was intended for brief diagnostic messages (hence the 160 character limit)</li>
							<li>it took off as <q>email for phone users</q> (asynchronous messaging)</li>
							<li>it now is a major source of income for all mobile operators</li>
						</ul>
						<li>SMS often is used as a ubiquitous and simple messaging channel</li>
						<ul>
							<li>only requires cell phone service and no Internet connection</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="transport-internet">
				<title>Internet Transport</title>
				<slide>
					<title>Raw Data</title>
					<ul>
						<li>Internet connectivity establishes bare data services</li>
						<li>Internet connectivity allows various application protocols</li>
						<ul>
							<li>email is one popular set of application protocols</li>
							<li>file transfer (old-style or file sharing) is popular as well</li>
							<li><em href="http://en.wikipedia.org/wiki/Voice_over_Internet_Protocol">Voice over IP</em> becomes increasingly popular</li>
							<li>video telephony has some success in professional settings</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Web Traffic</title>
					<ul>
						<li>Web traffic is just one type of Internet traffic</li>
						<li>Browsers and servers exchange <em>HTTP messages</em></li>
						<li>Browsers can send requests without loading a new page (Ajax)</li>
						<li>Applications often also use Web traffic to talk to servers</li>
						<ul>
							<li>non-Web traffic often is affected by network filters (firewall)</li>
							<li>Web services can be used by applications <em>and</em> by browsers</li>
						</ul>
						<li>Web services have become the standard way how to provide services</li>
						<ul>
							<li>many business-level services are exposed as Web services</li>
							<li>building mobile applications should be based on Web services</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<slide>
			<title>Conclusion</title>
			<ul>
				<li>The mobile landscape is diverse and complicated</li>
				<li>Technology is only one part in a more complex picture</li>
				<li>Major parts of this landscape are evolving continually</li>
				<li>5 years from now, many things will be very different</li>
			</ul>
		</slide>
	</presentation>
	<presentation id="history">
		<title short="History">Mobile Applications History</title>
		<date>2010-01-25</date>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/a_brief_history_of_mobile" title="Mobile Design and Development; Chapter 1: A Brief History of Mobile">Mobile History</a></toc>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Environment Setup">A1: Setup</a> (assigned: 1/25; due: 2/1)</toc>
		<toc class="resources"><a href="http://en.wikipedia.org/wiki/Personal_Digital_Assistant" title="Wikipedia Entry: Personal Digital Assistant">Wikipedia:&#160;PDA</a>&#160;· <a href="http://en.wikipedia.org/wiki/Psion" title="Wikipedia Entry: Psion">Wikipedia:&#160;Psion</a>&#160;· <a href="http://en.wikipedia.org/wiki/Palm_%28PDA%29" title="Wikipedia Entry: Palm PDA">Wikipedia:&#160;Palm</a></toc>
		<toc class="abstract">The design and development of mobile applications has already gone through a number of stages of development, and the current landscape very likely will change substantially into yet unknown directions. Looking back at the short but surprisingly varied <q>History of Mobile Applications</q> not only is a good exercise in better understanding different approaches, but it is also interesting to look at why certain approaches may have failed or succeeded. Often, the deciding factors are not just technical, but economical and social issues play an important role as well.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="mobileoffline">
			<title>Offline Mobile</title>
			<slide id="pda">
				<title short="PDA">Personal Digital Assistant (PDA)</title>
				<ul>
					<li>Introduced as a new class 1992 for the <a href="http://en.wikipedia.org/wiki/Apple_Newton">Apple Newton</a></li>
					<li>Personal data management and personal productivity applications</li>
					<li>Offline and regular synchronization/backup as the initial model</li>
					<li>Online (or at least occasional online) went through several stages:</li>
					<ul>
						<li>dial-up services (modem) for Internet connectivity</li>
						<li>IrDA for synchronization with other devices</li>
						<li>Bluetooth for synchronization with other devices</li>
						<li>cell phone data services (GPRS, EDGE, 3G) as <q>advanced dial-up</q></li>
						<li>Wi-Fi for using hotspots and home/office networks</li>
					</ul>
					<li><q>Smartphone</q> seems to be the new term for <q>PDA</q></li>
				</ul>
			</slide>
			<slide>
				<title>PDAs</title>
				<img src="psion-series3c.jpg" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Psion_Series_3"/>
			</slide>
			<slide>
				<title>The Last Psion</title>
				<img src="psion-series5mx.jpg" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Psion_Series_5"/>
			</slide>
			<slide>
				<title>The First Netbook (1999)</title>
				<img src="psion-netbook.jpg" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Psion_netBook"/>
			</slide>
			<slide>
				<title>PDA/Phone Merger</title>
				<img src="palm-pilot.jpg" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Palm_%28PDA%29"/>
			</slide>
			<slide>
				<title>Smartphone Sales Q2 2009</title>
				<img src="smartphone-os-q2-2009.png" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Smartphone"/>
			</slide>
		</part>
		<part id="paralleluniverses">
			<title>Parallel Universes</title>
			<slide>
				<title>Walled Gardens</title>
				<ul>
					<li>Combining access and content</li>
					<li>Attractive in early stages and for several reasons</li>
					<ul>
						<li>security and safety and easier to implement and control</li>
						<li>market models are easier to develop and more predictable</li>
					</ul>
					<li>Walled gardens often have a limited life-span</li>
					<ul>
						<li>selection and curation of content is expensive</li>
						<li>users may move to competitors or just <q>leave the garden</q></li>
						<li>an increasing disconnect between the garden and the world</li>
					</ul>
				</ul>
			</slide>
			<part id="imode">
				<title short="imode">i-mode</title>
				<slide>
					<title>Access and Services</title>
					<img src="i-mode.png" style="float : right ; margin : 0 1em 2em 2em ; " href="http://en.wikipedia.org/wiki/I-mode"/>
					<ul>
						<li>Mix of access and content technologies</li>
						<li>Developed and deployed by one mobile carrier (<a href="http://en.wikipedia.org/wiki/NTT_DoCoMo">DoCoMo</a>)</li>
						<li>Launched in 1999 as a tightly controlled walled garden</li>
						<ul>
							<li>content and services are hosted in centralized data centers</li>
							<li>the business model was predefined by the environment</li>
						</ul>
						<li>Successful not only for market but also for social reasons</li>
						<ul>
							<li>talking on the phone in the public is frowned on in Japan</li>
							<li>data-oriented services (chatting, messaging) are important in Japan</li>
						</ul>
						<li>i-mode never caught on outside of Japan</li>
						<ul>
							<li>2006: i-mode 46.8 million customers in Japan; 5 million in the rest of the world</li>
							<li>no other mobile operator was able to establish a working market</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="wap">
				<title short="WAP">Wireless Application Protocol (WAP)</title>
				<slide>
					<title>The Internet in your Pocket</title>
					<ul>
						<li>WAP is just a set of access technologies</li>
						<ul>
							<li>no content landscape/environment as in <link href="imode"/></li>
							<li>WAP started with zero content and high hopes for adoption</li>
						</ul>
						<li>WAP had some very questionable approaches to security</li>
						<ul>
							<li><link href="wap1"/> did not allow end-to-end encryption</li>
							<li>providers always can listen in by running WAP gateways</li>
							<li>security-sensitive providers refused to deploy any WAP services</li>
						</ul>
						<li><link href="wap2"/> cleaned up <link href="wap1"/> but came too late</li>
						<ul>
							<li>mostly a set of profiles for existing Internet technologies</li>
							<li><link href="wap1"/>'s design flaws tarnished the <q>WAP</q> brand name</li>
						</ul>
					</ul>					
				</slide>
				<part id="wap1">
					<title short="WAP1">WAP 1.x</title>
					<slide>
						<title>Rebuild Everything</title>
						<ul>
							<li>New specifications for almost any Web standard</li>
							<ul>
								<li>WML (extended subset of HTML)</li>
								<li>WMLScript (incompatible with JavaScript)</li>
								<li>WBXML (binary encoding of XML)</li>
								<li>WBMP (derived from PNG but incompatible)</li>
								<li>transport protocols (WCMP, WDP, WTP)</li>
							</ul>
							<li>Secure connections were not end-to-end but through a WAP gateway</li>
							<ul>
								<li>not acceptable for security-sensitive applications (e.g., e-banking)</li>
								<li>this design <a href="http://www.eff.org/deeplinks/2010/01/some-lessons-att-facebook">still has consequences 10 years later</a></li>
							</ul>
							<li>Some banks set up their own WAP gateways</li>
							<ul>
								<li>technically a working solution (<q>trusted WAP gateway</q>)</li>
								<li>terrible for consumers because of WAP configuration issues</li>
							</ul>
						</ul>
					</slide>
					<slide id="wap1-protocols">
						<title>WAP 1.x Protocol Stack</title>
						<img src="wap1-layer-diagram.gif" style="width : 90% ; margin : 2em ; " href="http://www.4k-associates.com/4K-Associates/IEEE-L7-WAP-BIG.html"/>
					</slide>
				</part>
				<part id="wap2">
					<title short="WAP2">WAP 2.x</title>
					<slide>
						<title>Reuse Existing Standards</title>
						<ul>
							<li>WAP 2.x completely replaced the entire <link href="wap1-protocols"/></li>
							<li>Failure in Europe and the USA, successful in Japan</li>
							<li>WML is replaced by a profile of XHTML</li>
							<ul>
								<li>much easier the develop than WML content (tool support)</li>
							</ul>
							<li>WAP gateways now are regular HTTP gateways</li>
							<ul>
								<li>end-to-end transfer with open and popular protocols</li>
								<li>no more security issues for encrypted connections</li>
								<li>gateways can add information to requests (phone numbers, location, …)</li>
							</ul>
						</ul>
					</slide>
				</part>
			</part>
		</part>
		<part>
			<title>Runtime Environments</title>
			<slide>
				<title>Content vs. Applications</title>
				<ul>
					<li><q>Traditional HTML</q> is static content</li>
					<ul>
						<li>initial browsers did not support scripting</li>
						<li>the <q href="http://en.wikipedia.org/wiki/Browser_wars">browser wars</q> made scripting very cumbersome</li>
						</ul>
					<li>Multimedia content was required for commercial content</li>
					<ul>
						<li><link href="java">Java</link> was an existing (but heavy) solution from enterprise IT</li>
						<li><link href="flash">Flash</link> evolved from a more content-centric perspective</li>
					</ul>
					<li>Today's browsers are runtime environments themselves</li>
					<ul>
						<li>rich and fairly robust scripting environments</li>
						<li>more limited access to OS resources than add-ons</li>
					</ul>
				</ul>
			</slide>
			<part id="java">
				<title short="Java">Java</title>
				<slide>
					<title>Write Once, Run Anywhere</title>
					<img src="duke-wave.png" style="float : right ; margin : 0 1em 2em 2em ; width : 20% " href="http://en.wikipedia.org/wiki/File:Wave.svg" title="Duke Waving"/>
					<ul>
						<li>Java is a runtime environment supported on many operating systems</li>
						<li>Strictly speaking, Java is three different things</li>
						<ol>
							<li>an object-oriented programming language</li>
							<li>an extensive set of class libraries as supporting environment</li>
							<li>the <em href="http://en.wikipedia.org/wiki/Java_Virtual_Machine">Java Virtual Machine (JVM)</em> for executing <em href="http://en.wikipedia.org/wiki/Java_bytecode">Java Bytecode</em></li>
						</ol>
						<li>Complete Java installations (<em href="http://java.sun.com/javase/">Java SE</em>) are very heavyweight</li>
						<ul>
							<li>the runtime support for programs is rich and complex</li>
							<li>Java has it roots in enterprise IT and not in lightweight Web</li>
						</ul>
						<li><em href="http://en.wikipedia.org/wiki/Java_applet">Java Applets</em> are a special kind of Java app</li>
						<ul>
							<li>running inside a browser (can be started from the Web)</li>
							<li>running inside a sandbox (security model for limiting OS access)</li>
						</ul>
					</ul>
				</slide>
				<slide id="javame">
					<title short="Java ME">Java Micro Edition (Java ME)</title>
					<ul>
						<li>Java ME (formerly J2ME) is a smaller version of the full Java SE</li>
						<ul>
							<li>different devices implement different profiles of Java ME functionality</li>
							<li><em href="http://en.wikipedia.org/wiki/Mobile_Information_Device_Profile">MIDP</em> defines a set of standardized profiles</li>
							<li>many mobile devices implement some MIDP version plus some additional <em href="http://en.wikipedia.org/wiki/Java_Community_Process">JSR</em>s</li>
						</ul>
						<li>Installing J2ME applications often is a cumbersome process</li>
						<ul>
							<li>installation somewhere outside of the usual Web access</li>
							<li>procedures vary widely between different phone models</li>
						</ul>
						<li>Running J2ME applications can be a frustrating process</li>
						<ul>
							<li>device makers are using different J2ME implementations</li>
							<li>feature support and implementation quality vary widely</li>
						</ul>
					</ul>
				</slide>
				<slide id="javafx">
					<title>JavaFX</title>
					<ul>
						<li>Shedding the <link href="javame"/> brand</li>
						<li>More Web standards for developing content</li>
						<ul>
							<li>CSS as a way to specify the layout of content</li>
							<li><em href="http://en.wikipedia.org/wiki/JavaFX_Script">scripting</em> as a faster way for application development</li>
						</ul>
						<li>Success and support currently unclear</li>
					</ul>
				</slide>
			</part>
			<part id="flash">
				<title short="Flash">Flash</title>
				<slide>
					<title>Multimedia on the Web</title>
					<ul>
						<li>Robust scripting for desktop browsers</li>
						<ul>
							<li>good strategy for deploying Flash as a browser add-on</li>
							<li>gets harder with the growing variety of browsers (iPhone)</li>
						</ul>
						<li>Started as an animation platform for content developers</li>
						<ul>
							<li>includes many of the functionality now developed in HTML5</li>
						</ul>
						<li>Many accessibility issues on Flash-oriented sites</li>
						<ul>
							<li>navigation can be completely inaccessible</li>
							<li>content can be hidden from search engines</li>
							<li>content is less fluid than even the simplest HTML/CSS</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
	</presentation>
	<presentation id="mechanics">
		<title short="Mechanics">Mobile Web Mechanics</title>
		<date>2010-01-27</date>
		<toc class="abstract">In this lecture, we look at the mechanics that are required to make Web-based mobile applications possible. This starts with basic networking capabilities, the question how individual devices establish Internet connectivity, and how the devices then communicate with the next <q>hop</q> in the communications chain. Based on this connectivity, we look at what it takes to establish a Web connection, how clients and servers are connected (how the data is actually routed), and how this can be influenced by intermediaries. Finally, we look in more detail at the endpoints of such a conversation, the browser and the server. How does a browser on a mobile device access the network, and how does a server receiving a request route it to the appropriate logic for processing it? We will discuss many of these in more detail later, but this lecture presents the big picture of how they all work together to make the mobile Web work.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="ipad">
			<title>Current Events</title>
			<slide>
				<title>iPad or iSlate?</title>
				<img src="ipad1.jpg" style="height : 65% ; margin : 4% ; " href="http://www.engadget.com/2010/01/27/live-from-the-apple-tablet-latest-creation-event/"/>
			</slide>
			<slide>
				<title>Bigger is Better</title>
				<img src="ipad2.jpg" style="height : 65% ; margin : 4% ; " href="http://www.engadget.com/2010/01/27/live-from-the-apple-tablet-latest-creation-event/"/>
			</slide>
		</part>
		<part id="connectivity">
			<title>Connectivity</title>
			<slide>
				<title>Networking Capabilities</title>
				<img src="gsm.png" style="float : right ; margin : 0 1em 2em 2em ; " href="http://en.wikipedia.org/wiki/File:GSMLogo.svg"/>
				<ul>
					<li>Mobile/Cell phone technologies</li>
					<ul>
						<li><a href="http://en.wikipedia.org/wiki/CDMA">CDMA</a> as the main technology in the U.S.</li>
						<li><a href="http://en.wikipedia.org/wiki/GSM">GSM</a> as the main technology everywhere else</li>
						<li><a href="http://en.wikipedia.org/wiki/3G">3G</a> for faster speeds (<a href="http://en.wikipedia.org/wiki/W-CDMA_%28UMTS%29">W-CDMA/UMTS</a> or <a href="http://en.wikipedia.org/wiki/CDMA2000">CDMA2000</a>)</li>
					</ul>
					<li>Several sub-technologies and sub-generations developed</li>
					<ul>
						<li><a href="http://en.wikipedia.org/wiki/General_Packet_Radio_Service">GPRS</a> for GSM networks (often referred to as 2.5G)</li>
						<li><a href="http://en.wikipedia.org/wiki/Enhanced_Data_Rates_for_GSM_Evolution">EDGE</a> for GSM networks (often referred to as 2.75G)</li>
						<li><a href="http://en.wikipedia.org/wiki/Evolution-Data_Optimized">EV-DO</a> for CDMA2000 networks</li>
					</ul>
					<li>Devices often are limited to one family of standards</li>
					<ul>
						<li>iPhone started as a GSM phone and there is no CDMA version</li>
						<li>Kindle started with EV-DO and needed to be adapted for Europe</li>
					</ul>
					<li><em>Internet Protocols</em> are able to bridge the network gaps</li>
					<ul>
						<li>that's the reason why it is called <em>Inter</em>net</li>
						<li>Internet protocols work in (almost all) possible network worlds</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Cell Phone Tower</title>
				<img src="cellphone-tower.jpg" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>Cell Phone Traffic</title>
				<ul>
					<li>Cell sizes vary between less than a mile and 30-45 miles</li>
					<ul>
						<li>sometimes limited by technology design (timing issues)</li>
						<li>always limited by the low-power signals emitted by devices</li>
					</ul>
					<li>Cell towers forward traffic into the carrier network</li>
					<ul>
						<li>in many cases using land lines (fiber optics)</li>
						<li>in remote locations via specialized radio relays</li>
					</ul>
					<li>Uncovered areas can be covered by satellite service</li>
					<ul>
						<li>world-wide network coverage for mobile devices</li>
						<li>expensive and requires dedicated satellite equipment</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Internet Connectivity</title>
				<ul>
					<li>Mobile carriers handle traffic inside their networks</li>
					<ul>
						<li>network call traffic never has to leave the carrier network</li>
						<li>data traffic and inter-network calls have to leave the network</li>
					</ul>
					<li><q>Joining the Internet</q> means to connect to a connected gateway</li>
					<ul>
						<li>mobile carriers often have few central gateway locations</li>
						<li>all mobile Internet traffic passes through these locations</li>
					</ul>
					<li>Technically, mobile networks work very much like company Intranets</li>
					<ul>
						<li>a centrally managed and organized infrastructure</li>
						<li>carriers can enforce their own rules and regulations within this network</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Where Does It Go?</title>
				<ul>
					<li>Internet connectivity needs a few essential configurations</li>
					<ul>
						<li><link href="ip-address">IP address</link> assigned to the device (global or local/NAT)</li>
						<li><em>subnet mask</em> (identification of directly reachable hosts)</li>
						<li><em>gateway</em> to be addressed for outgoing traffic</li>
						<li><em>DNS server(s)</em> for domain name lookups</li>
						<li>optionally, other servers such as time servers</li>
					</ul>
					<li>These configurations can be made dynamically or statically</li>
					<ul>
						<li>static configuration often is used for desktop/server computers</li>
						<li><a href="http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol">DHCP</a> is used for most other computers/devices</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Static Internet Configuration</title>
				<img src="iphone-wifi-static.jpg" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/File:Wyocellsite.jpg"/>
			</slide>
		</part>
		<part id="transport">
			<title>Transport</title>
			<slide>
				<title>Web Communications</title>
				<ul>
					<li>All Web traffic uses HTTP as application protocol</li>
					<ul>
						<li>a common language for request/response interactions</li>
					</ul>
					<li>Some Web traffic needs an additional layer of security</li>
					<ul>
						<li>most Web traffic uses unencrypted HTTP traffic</li>
						<li>some applications need security/privacy and use a security layer (SSL/TLS)</li>
					</ul>
					<li>HTTP as the common language allows for various optimizations</li>
					<ul>
						<li>traffic can be inspected and handled by <link href="intermediaries"/></li>
						<li>intermediaries can to inspection, optimization, or even conversion</li>
					</ul>
				</ul>
			</slide>
			<part id="end-to-end">
				<title>End-to-End Transport</title>
				<slide>
					<title>Establishing Connectivity</title>
					<ul>
						<li>HTTP traffic need a transport infrastructure</li>
						<ul>
							<li>clients open <em>connections</em> for sending HTTP traffic</li>
							<li>HTTP is a set of conventions regulating traffic over the transport</li>
						</ul>
						<li>Any Internet host can establish Internet connections</li>
						<ul>
							<li>IP is responsible for sending packets from and to computers</li>
							<li>TCP is responsible for handling connections between programs</li>
						</ul>
						<li>Routing on the Internet is a complex process</li>
						<ul>
							<li>backbone routers routinely exchange large routing tables</li>
							<li>Internet traffic always is packet-based, each IP packet travels alone</li>
							<li>IP is packet-based for robustness</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Secure Connections</title>
					<img src="ssl-tls-layers.gif" style="height : 65% ; margin : 4% ; " href="http://technet.microsoft.com/en-us/library/cc781476%28WS.10%29.aspx"/>
				</slide>
			</part>
			<part id="intermediaries">
				<title>Intermediaries</title>
				<slide>
					<title>Proxies</title>
					<ul>
						<li>HTTP is the language of the Web</li>
						<li>Clients may want to use proxies for a variety of reason</li>
						<ul>
							<li>proxies can make the Internet a more secure place (content filtering)</li>
							<li>proxies can make the Internet a safer place (content filtering)</li>
							<li>proxies can make the Internet faster (caching)</li>
							<li>proxies can allow access to controlled content (library proxy)</li>
							<li>proxies can be required by company policies (firewalls/logging)</li>
						</ul>
						<li>Proxies are HTTP intermediaries and exist in different configurations</li>
					</ul>
				</slide>
				<slide id="forward-proxy">
					<title>User Agent Proxies</title>
					<ul>
						<li>Configured by the client</li>
						<li>Useful if a client knowingly wants to delegate HTTP requests</li>
						<li>Can be global or for certain domains only</li>
						<ul>
							<li>library proxies must be used for accessing publisher sites</li>
						</ul>
					</ul>
				</slide>
				<slide id="reverse-proxy">
					<title>Reverse Proxies</title>
					<ul>
						<li>Configured by service providers</li>
						<li>Clients connect to the server (they think)</li>
						<ul>
							<li>server-side configuration redirects traffic to the reverse proxy</li>
						</ul>
						<li>Allows sophisticated server-side load balancing</li>
						<li>Similar goals can be attained with advanced DNS resolution</li>
						<ul>
							<li>resolve the same DNS name to different <link href="ip-address">IP address</link>es</li>
							<li>allows completely different IP addresses for the same server name</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Provider Proxies</title>
					<ul>
						<li>Configured by Internet providers</li>
						<ul>
							<li><q>intercepting</q> traffic on various levels</li>
							<li>useful for monitoring/filtering/augmentation/transcoding</li>
						</ul>
						<li><em>Monitoring</em> allows providers to track Internet traffic</li>
						<li><em>Filtering</em> can be based on connections or content</li>
						<li><em>Augmentation</em> can add information (e.g., user location)</li>
						<li><em>Transcoding</em> can change content (e.g., adapting to mobile browsers)</li>
					</ul>
				</slide>
			</part>
		</part>
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>Mobile Web requests need a complex infrastructure</li>
				<li>We will look at some aspects in greater detail</li>
				<li>Understanding the general mechanics is important</li>
				<li>Layering allows us to hide certain details</li>
				<ul>
					<li>Web developers should understand things down to TCP/SSL</li>
				</ul>
			</ul>
		</slide>
	</presentation>
	<presentation id="setup">
		<title short="Setup">Browser and Server Setup</title>
		<date>2010-01-29</date>
		<toc class="resources"><a href="http://filezilla-project.org/">Filezilla</a>&#160;· <a href="http://www.apachefriends.org/en/xampp.html">XAMPP</a></toc>
		<toc class="abstract">As a starting point for the assignments in this course, we are setting up a server and files on the server for accessing them with (mobile) clients. This lecture looks at some of the practical issues such as how file access works through a file system and through server software, how server software can even provide multiple access paths (virtual hosts), and how working with Web-oriented content can be made more convenient by setting up a local environment (a local Web server).</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="browser">
			<title>Browsers</title>
			<slide>
				<title>Sending HTTP Requests</title>
				<ul>
					<li>Clicking a link creates an HTTP request</li>
					<ul>
						<li>HTTP request to the host specified in the URI</li>
						<li>adding information about the client (HTTP metadata)</li>
						<li>adding information about client state (cookies)</li>
					</ul>
					<li>Ideally, a local HTTP library should take care of HTTP</li>
					<ul>
						<li>a common cache among all HTTP clients on the device</li>
						<li>HTTP should be considered as essential as TCP/IP</li>
					</ul>
					<li>Practically, many Web applications have their own HTTP handling</li>
					<ul>
						<li>different browsers all come with their own HTTP code</li>
						<li>caching across browser cannot be shared</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Browsers and Platforms</title>
				<ul>
					<li>Browsers use the platform's Internet support</li>
					<ul>
						<li>requesting a connection from the OS</li>
						<li>Internet connectivity handling is handled by the platform</li>
					</ul>
					<li>Mobile devices can be offline</li>
					<ul>
						<li>native applications should properly handle offline situations</li>
						<li>HTML5 adds a lot of offline capabilities to Web applications</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP Resources and Web Pages</title>
				<ul>
					<li>Web pages almost always need more than one resource to be displayed</li>
					<ul>
						<li>the page itself as HTML code rendered in the browser</li>
						<li>images that have to be included in the HTML rendering</li>
						<li>stylesheets that are required for the page layout</li>
						<li>scripting code that is required for dynamic HTML (DHTML)</li>
						<li>additional content embedded in the page (e.g., Flash)</li>
					</ul>
					<li>Ajax refers to pages that <em>dynamically</em> load new resources</li>
					<ul>
						<li>adding new content based on user interaction or other events</li>
						<li>closest possible way to resemble a <q>real application</q></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="server">
			<title>Servers</title>
			<slide>
				<title>Handling HTTP Requests</title>
				<ul>
					<li>Incoming connections are targeted at a specific program</li>
					<ul>
						<li>IP specifies the target machine (identified by an <link href="ip-address">IP address</link>)</li>
						<li>TCP specifies the target port (80 is the default)</li>
					</ul>
					<li>Web servers typically listen on port 80 for incoming requests</li>
					<ul>
						<li>if a connection is opened to port 80, it is assumed to carry HTTP</li>
						<li>servers getting non-HTTP traffic will respond with an error</li>
					</ul>
					<li>The request contains the request URI and metadata</li>
					<li>Servers must respond with a proper HTTP response</li>
					<ul>
						<li>in most cases the response contains the requested resource</li>
						<li>it may also contain an error message or a redirect response</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Serving HTTP Requests</title>
				<ul>
					<li><code>GET</code> requests ask to get a certain resource's representation</li>
					<li>URI identify resources to be manipulated through HTTP requests</li>
					<li>URI can identify various <q>kinds</q> of server-side resources</li>
					<ul>
						<li>a file to be retrieved from the file system</li>
						<li>a file to be retrieved and parsed and processed before being served</li>
						<li>a program to be invoked which will produce the resource</li>
					</ul>
					<li>HTTP servers can be standalone or integrated</li>
					<ul>
						<li>standalone servers must have a way to invoke server-side programs</li>
						<li>integrated servers run in the environment that executes the program</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Practical Issues</title>
			<slide>
				<title>File Access vs. Server Access</title>
				<ul>
					<li>Files are available through different methods</li>
					<ul>
						<li>access through the file system (command shell or file browser)</li>
						<li>server access through HTTP server (incoming HTTP requests)</li>
						<li>server access through FTP server (through FTP sessions)</li>
					</ul>
					<li>Accessing files is done by different <q>users</q></li>
					<ul>
						<li>logged in user through the file system</li>
						<li>configured account for server access</li>
						<li>server access must be granted by the file owner</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Local Servers</title>
				<ul>
					<li>HTTP servers respond to incoming requests from the Internet</li>
					<ul>
						<li><code href="http://en.wikipedia.org/wiki/Localhost">localhost</code> always refers to the host's own interface</li>
					</ul>
					<li>HTTP servers are available from various open source projects</li>
					<li>Better local testing of Web-oriented projects</li>
					<ul>
						<li>local servers replicate what will happen over the Web</li>
						<li>file-based access (<code>file</code> URI) can have unexpected side-effects</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>XAMPP</title>
				<img src="xampp-logo.png" style="float : right ; margin : 0 1em 2em 2em ; " href="http://www.apachefriends.org/en/xampp.html" title="XAMPP"/>
				<ul>
					<li><em href="http://www.apachefriends.org/en/xampp.html">XAMPP</em> is a software installation package</li>
					<ul>
						<li>available for a variety of platforms (Windows, Linux, MacOS, Solaris)</li>
						<li>Apache as Web server</li>
						<li>MySQL as a database</li>
						<li>PHP and Perl as programming languages</li>
						<li>control panel for ease of use</li>
					</ul>
					<li>Why running a Web server on the local computer?</li>
					<ul>
						<li>browsing local files using HTTP</li>
						<li>testing server configurations locally</li>
						<li>testing server-based code locally</li>
						<li>running a local database and a Web-based interface for it</li>
					</ul>
					<li>XAMPP is not required but recommended for this course</li>
				</ul>
			</slide>
			<slide>
				<title>Accessing Files</title>
				<ul>
					<li>The lecture pages are available at four different places</li>
					<ul>
						<li><code href="file:///c:/Documents%20and%20Settings/dret/Desktop/drectures/mobapp-spring10">file:///c:/Documents%20and%20Settings/dret/Desktop/drectures/mobapp-spring10</code></li>
						<li><code href="http://localhost/drectures/mobapp-spring10">http://localhost/drectures/mobapp-spring10</code></li>
						<li><code href="ftp://tik50x.ethz.ch/home/dret/public_html/lectures/mobapp-spring10">ftp://tik50x.ethz.ch/home/dret/public_html/lectures/mobapp-spring10</code></li>
						<li><code href="http://dret.net/lectures/mobapp-spring10">http://dret.net/lectures/mobapp-spring10</code></li>
					</ul>
					<li>Using a local server makes local development easier</li>
					<ul>
						<li>uploading the working result to the server should <q>just work</q></li>
						<li>however, to really make it <q>just work</q>, URIs must be used responsibly</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Names</title>
				<ul>
					<li>One server can have more than one name</li>
					<ul>
						<li>names are resolved to <link href="ip-address">IP address</link>es for establishing connections</li>
						<li>multiple names can be very useful for hosting environments</li>
					</ul>
					<li>Requests to the same server go to the same IP address</li>
					<ul>
						<li>servers use a special request field to learn about the host</li>
						<li>requests then are routed to the configuration for that host</li>
					</ul>
					<li>Server space is available through <code>people</code> and <code>people</code></li>
					<ul>
						<li>both servers are configured to look into <code>~/public_html</code></li>
						<li>the <code>mobapp</code> configuration writes to log files in <code>~/mobapp-logs</code></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Relative URIs</title>
				<ul>
					<li>URIs are identifications of resources on the Web</li>
					<ul>
						<li>they can use a variety of access protocols (HTTP, HTTPS, FTP, …)</li>
						<li>they can be relative or absolute</li>
					</ul>
					<li>Relative URIs are interpreted relative to their context</li>
					<ul>
						<li><code href="http://dret.net/netdret">http://dret.net/netdret</code> points to <code href="http://dret.net/netdret/aquadret.jpg">aquadret.jpg</code></li>
						<li>dereferencing the image link works regardless of the page's base URI</li>
						<li>HTML and JPEG always have to be managed together</li>
					</ul>
					<li>Deciding on how to use absolute and relative URIs is important</li>
					<ul>
						<li>relative: for references to resources in the same management domain</li>
						<li>absolute: for references to resources that are managed differently</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="html+css+dom">
		<title short="HTML/CSS/DOM">HTML, CSS, and DOM</title>
		<date>2010-02-01</date>
		<toc class="reading"></toc>
		<toc class="resources"><a href="http://www.w3.org/TR/CSS21/" title="W3C CSS 2.1 Specification">CSS Spec</a>&#160;· <a href="http://www.w3.org/TR/CSS21/propidx.html" title="W3C CSS 2.1: Property Index">CSS Properties</a>&#160;· <a href="http://www.w3schools.com/css">CSS&#160;Tutorial</a>&#160;· <a href="http://jigsaw.w3.org/css-validator/">CSS&#160;Validator</a></toc>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Environment Setup">A2<sup>1</sup>: Web App (flickr)</a> (assigned: 2/1; due: 2/9)</toc>
		<toc class="abstract">The <em>Hypertext Markup Language (HTML)</em> is the most important content type on the Web. Modern browsers are expected to support HTML, CSS for styling the content of a HTML page, and scripting so that server-supplied scripting code can run in the browser, update the HTML and/or CSS, and interact with the user or the browser. This lecture presents an overview of how the building blocks of HTML, CSS, DOM, and scripting fit together to provide Web applications with a standardized and robust platform.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="html">
			<title short="HTML">Hypertext Markup Language (HTML)</title>
			<slide>
				<title>HTML Definition</title>
				<ul>
					<li>HTML's structure is defined by a <em>Document Type Definition (DTD)</em></li>
					<ul>
						<li>formally speaking, a DTD defines the grammar of the HTML language</li>
						<li>(and if you really want to know, <em>SGML</em> defines the syntax)</li>
						<li>colloquially speaking, a DTD defines how to combine elements and attributes</li>
					</ul>
				</ul>
				<listing src="html4-strict.dtd" line="513-517" title="Syntax for Unordered Lists (UL)"/>
				<listing src="html4-strict.dtd" line="521-524" title="Syntax for List Items (LI)"/>
				<listing src="html4-strict.dtd" line="258" title="Definition of %flow;"/>
				<listing src="html4-strict.dtd" line="254-256" title="Definition of %block;"/>
			</slide>
			<slide id="validation">
				<title>HTML Validation</title>
				<ul>
					<li><em>Web-based tools</em> allow validation from anywhere</li>
					<li><a href="http://www.w3.org">W3C</a>'s <a href="http://validator.w3.org/">markup validation service</a> supports three modes:</li>
					<ol>
						<li>validation by URI (pointing at a random Web page)</li>
						<li>validation by file upload (allows validation of non-Web files)</li>
						<li>validation by copy/paste (lightweight mode for small experiments)</li>
					</ol>
					<li>Markup validation is only one facet of checking Web content</li>
					<ul>
						<li><a href="http://jigsaw.w3.org/css-validator/">checking CSS code for validity</a></li>
						<li><a href="http://validator.w3.org/mobile/">checking Web pages for mobile content (i.e., simpler HTML)</a></li>
						<li><a href="http://validator.w3.org/checklink">checking Web pages for broken links</a></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTML and WYSIWYG</title>
				<ul>
					<li>Thinking of HTML as a layout-description language is wrong</li>
					<li>HTML has been designed as a structure-description language</li>
					<ul>
						<li>structured contents can be reformatted and reflowed</li>
					</ul>
					<li>HTML rendering depends on a many client properties</li>
					<ul>
						<li>screen/window size, resolution, and color depth</li>
						<li>different available fonts</li>
						<li>fonts with the same family name but different metrics</li>
						<li>different hyphenation algorithms</li>
						<li>hyphenation setting defaults</li>
						<li>hyphenation dictionaries</li>
						<li>different size spaces</li>
						<li>different line-breaking algorithms</li>
						<li>different widow/orphan/keeptogether rules</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Web Browsers</title>
				<img src="web-browser-usage.png" style="float : right ; width : 40% ; margin : 0 1em 2em 2em ; " href="http://en.wikipedia.org/wiki/File:Web_browser_usage_share.svg" title="Web Browser Usage"/>
				<p><span style="border:#0000ff solid 1px;; background-color:#0000ff; color:#0000ff">██</span>&#160;Internet Explorer (59.21%)</p>
				<p><span style="border:#ffff00 solid 1px;; background-color:#ffff00; color:#ffff00">██</span>&#160;Mozilla Firefox (28.29%)</p>
				<p><span style="border:#00ff00 solid 1px;; background-color:#00ff00; color:#00ff00">██</span>&#160;Chrome (5.02%)</p>
				<p><span style="border:#00ffff solid 1px;; background-color:#00ffff; color:#00ffff">██</span>&#160;Safari (4.54%)</p>
				<p><span style="border:#ff0000 solid 1px;; background-color:#ff0000; color:#ff0000">██</span>&#160;Opera (1.68%)</p>
				<p><span style="border:#ff00ff solid 1px;; background-color:#ff00ff; color:#ff00ff">██</span>&#160;Other (1.26%)</p>
			</slide>
			<slide>
				<title>Web Browser History</title>
				<img src="web-browser-history.png" style="height : 75% ; margin : 2% ; " href="http://en.wikipedia.org/wiki/File:Usage_share_of_web_browsers_%28Source_Net_Applications%29.svg" title="Web Browser History"/>
			</slide>
		</part>
		<part id="css">
			<title short="CSS">Cascading Style Sheets (CSS)</title>
			<slide>
				<title>CSS in Action</title>
				<listing src="zengarden.html" line="17-30" href="http://www.csszengarden.com/"/>
			</slide>
			<slide>
				<title>HTML and CSS</title>
				<ul>
					<li>CSS specifies how <link href="html">HTML</link> elements are formatted</li>
					<ol>
						<li>formatting can be attached to every element (redundant inside document)</li>
						<li>formatting can be included in document (redundant across documents)</li>
						<li>separate CSS files describe the formatting (best reuse)</li>
					</ol>
					<li>Any combination of these methods is possible</li>
				</ul>
				<listing src="css-usage.html" line="3-13"/>
			</slide>
			<slide>
				<title>Formatting Model</title>
				<ul>
					<li><link href="css-properties"/> are central to the CSS formatting model</li>
					<ol>
						<li>create a document tree (the <link href="dom">DOM</link> tree)</li>
						<li>identify the media type (e.g., <css>screen</css> or <css>print</css>)</li>
						<li>retrieve all stylesheets required for the media type</li>
						<li>assign values to all properties in the document tree</li>
						<li>generate a <em>formatting structure</em> (a different tree)</li>
						<li>render the formatting structure on the target medium</li>
					</ol>
					<li>Properties control the rendering of elements</li>
					<li>Styling in CSS means assigning values to properties</li>
				</ul>
			</slide>
			<slide id="css-properties">
				<title>CSS Properties</title>
				<ul>
					<li>Properties define how elements are formatted</li>
					<ul>
						<li>they define a specific facet of formatting</li>
						<li>they may have interdependencies with other properties</li>
						<li>they can be assigned explicitly</li>
						<li>they may be defined through <link href="css-cascading"/> or <link href="css-inheritance"/></li>
					</ul>
					<li>A property has a name and is used in a name/value-pair</li>
					<ul>
						<li>the name identifies the property that is being set</li>
						<li>the value space depends on the property</li>
						<li>some properties accept complex values</li>
						<li>sets of values: <css>p { font : bold italic large Palatino }</css></li>
						<li>sequences of values: <css>p { font-family : "Segoe UI", verdana, helvetica, arial, sans-serif }</css></li>
					</ul>
					<li>Property specifications can be grouped</li>
					<ul>
						<li><css>.thinboxed { border-width : 1px ; padding : 10px ; margin : 5px }</css></li>
					</ul>
				</ul>
			</slide>
			<slide id="css-selectors">
				<title>CSS Selectors</title>
				<ul>
					<li><link href="css-properties"/> are applied to elements</li>
					<ul>
						<li>properties can be directly applied in an element's <htmla>style</htmla> attribute</li>
						<li>in all other cases, <em>selectors</em> are used to select the styled elements</li>
					</ul>
					<li>Selectors are good for reusable CSS code</li>
					<ul>
						<li>identifying the most appropriate formatting classes is not easy</li>
						<li>planning for CSS for a larger site is a difficult task</li>
					</ul>
					<li>CSS project management should separate selectors and properties</li>
					<ol>
						<li>selectors are about which things should be identified and styled</li>
						<li>properties are about how this styling is implemented</li>
					</ol>
				</ul>
			</slide>
			<slide id="css-cascading">
				<title>Cascading</title>
				<ul>
					<li>Stylesheets may have three different origins</li>
					<ol>
						<li><em>page authors</em> associate CSS with their pages</li>
						<li><em>users</em> configure their browser to use some CSS</li>
						<li><em>user agents (browsers)</em> have built-in CSS how to style content</li>
					</ol>
					<li>Conflicts must be resolved using the following algorithm</li>
					<ol>
						<li>find all matching declarations (matching media type and selector)</li>
						<li>sort according to importance (browser &lt; user &lt; author)</li>
						<li>same importance must be sorted by specificity (more specific selectors)</li>
						<li>finally, sort by order in which they were specified</li>
					</ol>
					<li><css>!important</css> rules can influence the algorithm</li>
					<ul>
						<li>they are interpreted in step 2 (sorting by importance)</li>
						<li>browser &lt; user &lt; author &lt; author(important) &lt; user(important)</li>
					</ul>
				</ul>
			</slide>
			<slide id="css-inheritance">
				<title>Inheritance</title>
				<ul>
					<li>Properties often are inherited by children</li>
					<ul>
						<li>setting a table's <css>color</css> sets the <css>color</css> for all contents</li>
						<li>without inheritance, CSS stylesheets would have to be very large</li>
					</ul>
					<li>Inheritance is mostly intuitive</li>
					<ul>
						<li>in reality, it is a bit more complicated</li>
					</ul>
					<ol>
						<li><em>specified value:</em> what the property specified (<link href="css-cascading"/>, inheritance, or initial)</li>
						<li><em>computed value:</em> computed based on the environment (e.g., <css>ex</css> → <css>px</css>)</li>
						<li><em>used value:</em> converted to an absolute value (e.g., percentage widths)</li>
						<li><em>actual value:</em> specific for the environment (e.g., borders with pixel fractions)</li>
					</ol>
				</ul>
			</slide>
		</part>
		<part id="dom">
			<title short="DOM">Document Object Model (DOM)</title>
			<slide>
				<title>From HTML to DOM</title>
				<ul>
					<li><link href="html">HTML</link> is a representation for hypermedia documents</li>
					<ul>
						<li>a representation is required to store and transmit the document</li>
						<li>HTML uses <em>markup</em> for representing the document structure</li>
					</ul>
					<li>Browsers must render HTML documents (i.e., apply CSS and execute JavaScript)</li>
					<ol>
						<li><http>GET</http> HTML from server and receive as <mime>text/html</mime> document</li>
						<li>parse document and deal with any errors by <q>fixing them</q></li>
						<li>interpret document as if it had been error-free</li>
						<li><http>GET</http> all additional resources (CSS, images, JavaScript, …)</li>
						<li>build internal model (DOM) based on error-free interpretation</li>
						<li>apply CSS rules to determine styling of document (e.g., margins and font sizes)</li>
						<li>render into visual structure</li>
						<li>start executing JavaScript code</li>
						<li>listen for events (keyboard, mouse, timer) and execute code</li>
						<li>discard everything and start over when user navigates to a different page</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Browser Handling of HTML</title>
				<img style="width : 90% ; margin : 2% ; " src="html-parser.png" title="Browser Handling of HTML"/>
			</slide>
			<slide id="dom-document">
				<title>Document</title>
				<ul>
					<li>The document (HTML) is the <em>interface language for Web applications</em></li>
					<li>Most programming environments have visual interface models</li>
					<ul>
						<li>almost everything has moved to <em>window-oriented interfaces</em></li>
						<li>Windows, MacOS, and Linux provide similar visual metaphors</li>
					</ul>
					<li>Web applications must use HTML as their model for the interface</li>
					<ul>
						<li><a href="../web-fall09/forms">HTML forms</a> are a simple way to build an interface</li>
						<li>forms can be extended with client-side helpers (validation, repeating entries)</li>
					</ul>
				</ul>
			</slide>
			<slide id="dom-object">
				<title>Object</title>
				<ul>
					<li>Documents are static, programming is dynamic</li>
					<ul>
						<li>documents and code must be connected</li>
						<li><em>objects</em> are a common abstraction in programming languages</li>
					</ul>
					<li>Objects usually have a <em>type</em> and <em>methods</em></li>
					<ul>
						<li><em>types</em> for HTML-based objects are based on HTML's elements</li>
						<li><em>methods</em> define the allowed to interact with objects</li>
						<li>interactions can be read-only or they can change the document structure</li>
					</ul>
				</ul>
				<listing src="nicetitle.js" line="22-32" title="Improving the mouseovers for HTML title attributes (JavaScript)"/>
			</slide>
			<slide id="dom-model">
				<title>Model</title>
				<ul>
					<li>Models are idealized/abstract views of something</li>
					<li>Model interfaces allow to expose that idealized/abstract view</li>
					<li>DOM introduced a <em>common way of how browsers deal with HTML</em></li>
					<ul>
						<li>without a DOM, there can be no interoperable scripting</li>
					</ul>
					<li>Abstractions are also limitations</li>
					<ul>
						<li>some vendors add/support <q>extensions</q> to the basic DOM model</li>
						<li>any code based on these extensions is not interoperable</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Markup to Trees</title>
				<ul>
					<li>Browsers build a DOM tree from the (fixed) markup</li>
					<ul>
						<li>scripting code never works on the markup text, it works on the tree</li>
					</ul>
					<li>DOM trees are an abstraction of the markup</li>
					<ul>
						<li>trees provide convenient navigation facilities</li>
						<li>abstractions provide an insulation against irrelevant markup details</li>
					</ul>
					<li>DOM is available in a large number of programming languages</li>
					<ul>
						<li>JavaScript is the language supported in Web browsers</li>
						<li>DOM is also available for Java, C, C++, Python, Perl, C#, Ruby, …</li>
					</ul>
				</ul>
			</slide>
			<slide id="domhistory">
				<title>DOM History</title>
				<ul>
					<li>DOM0 was invented by Netscape (backing LiveScript/JavaScript)</li>
					<li>DOM1 was the first DOM version produced by the W3C</li>
					<li>DOM2 is the currently available stable version of DOM</li>
					<ul>
						<li>major changes to be compliant with XML and the XML Infoset</li>
					</ul>
					<li>DOM3 is highly modularized and still under development</li>
					<ul>
						<li>more XML technologies such as the ability to use XPath</li>
					</ul>
					<li>HTML5 extends the landscape of DOM</li>
					<ul>
						<li>HTML5 itself adds new capabilities to DOM</li>
						<li>a variety of additional specs add even more functionality</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="scripting" external="javascript.pdf">
		<title short="Scripting">Scripting with JavaScript</title>
		<date>2010-02-03</date>
		<toc class="author">Nick Doty</toc>
		<toc class="resources"><a href="http://getfirebug.com/">Firebug</a></toc>
		<toc class="abstract">This lecture introduces JavaScript as a programming language and discusses some of the most important features of the language. We also look at how to use JavaScript inside of a browser interactively with a debugging tool called <em>Firebug</em>, and start looking at some of the ways in which <em>jQuery</em> makes Web development with JavaScript less programming-heavy, more reliable, and more declarative.</toc>
	</presentation>
	<presentation id="jquery" external="jquery.pdf">
		<title short="jQuery">Introduction to jQuery</title>
		<date>2010-02-05</date>
		<toc class="author">Ryan Greenberg</toc>
		<toc class="resources"><a href="http://jquery.com/">jQuery</a></toc>
		<toc class="abstract">In this second lecture on scripting, we look in more detail at the jQuery framework. We focus on how <em>selectors</em> allow to select nodes in the DOM tree, how these can be manipulated using jQuery methods, and how they can be used as starting point for <em>traversal</em> of the DOM tree. We also look at some of the mechanics of event handlers and some of the finer points of when and how event handlers and events should be managed in jQuery.</toc>
	</presentation>
	<presentation id="structured-data">
		<title short="Structured Data">Structured Data: XML and JSON</title>
		<date>2010-02-08</date>
		<toc class="reading"></toc>
		<toc class="resources"><a href="http://en.wikipedia.org/wiki/Dynamic_HTML" title="Wikipedia: Dynamic HTML (DHTML)">Wikipedia: DHTML</a>&#160;· <a href="http://en.wikipedia.org/wiki/Ajax_%28programming%29" title="Wikipedia: Ajax (Programming)">Wikipedia: Ajax</a>&#160;· <a href="http://www.w3.org/TR/REC-xml/" title="W3C XML 1.0 Specification">XML Spec</a>&#160;· <a href="http://dret.net/netdret/publications#wil06l" title='Erik Wilde, "Structuring Content with XML", 10th International Conference on Electronic Publishing (ELPUB 2006), Bansko, Bulgaria, June 2006'>Structuring Content with XML</a>&#160;· <a href="http://www.json.org/" title="Introducing JSON">JSON</a>&#160;· <a href="http://blog.technologyofcontent.com/2010/01/json-vs-xml/">JSON vs. XML</a></toc>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Environment Setup">A2<sup>2</sup>: Web App (twitter)</a> (assigned: 2/8; due: 2/16)</toc>
		<toc class="abstract">Many mobile applications are based on communications with a service. In most cases, these communications are based on structured data, with the client receiving and/or sending structured data to a service. The two most popular data formats for exchanging structured data in use today are the <em>Extensible Markup Language (XML)</em> and the <em>JavaScript Object Notation (JSON)</em>. This lecture explains and compares these two formats, and is the foundation for the following lectures about <em>Content Syndication</em> and <em>Ajax</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide id="dhtml">
			<title short="DHTML">Dynamic HTML (DHTML)</title>
			<listing src="fading.html"/>
		</slide>
		<slide>
			<title>Ajax = DHTML + HTTP</title>
			<ul>
				<li><link href="dhtml"/> uses JavaScript <q>locally</q> (changes in the browser)</li>
				<ul>
					<li>the scripting code reacts to user events and accesses the DOM structure</li>
					<li>changes are either hardcoded or reactions to user events</li>
				</ul>
				<li><link href="ajax">Ajax</link> adds an <link href="http-request">HTTP request</link> method to JavaScript</li>
				<ul>
					<li>scripting code can now request additional data from an HTTP server</li>
					<li>changes can thus be made based on any data received from the server</li>
				</ul>
				<li>Ajax dramatically reduces the number of page reloads</li>
				<ul>
					<li>any change of the page can be done without a complete reload</li>
					<li>based on user interactions, parts of the page can be reloaded</li>
				</ul>
				<li>Ajax has the same interoperability problems as DHTML</li>
			</ul>
		</slide>
		<slide>
			<title>Ajax and DHTML</title>
			<img style="width : 90% ; margin : 2% ; " src="ajax.png" title="Comparison of Ajax and DHTML"/>
		</slide>
		<slide id="xmlhttprequest">
			<title>JavaScript and XML</title>
			<ul>
				<li>The <code>XMLHttpRequest</code> API has been built for requesting <link href="xml">XML</link> via HTTP</li>
				<ul>
					<li>this is useful because XML is a very popular data format</li>
					<li>all requested data has to be processed by using DOM traversal in JavaScript</li>
				</ul>
				<li>JavaScript does not have XML as its internal data model</li>
				<ul>
					<li>the XML received via <code>XMLHttpRequest</code> has to be parsed into a DOM tree</li>
					<li>DOM access in JavaScript is inconvenient for complex operations</li>
					<li>alternatively, the XML can be mapped to JavaScript objects (also requires parsing)</li>
				</ul>
				<li><link href="json">JSON</link> encodes data as JavaScript objects</li>
				<ul>
					<li>more efficient for the consumer if the consumer is written in JavaScript</li>
					<li>this turns an XML service into an object-oriented service</li>
					<li>for large-scale applications, it might make sense to provide XML and JSON</li>
					<li>using <link href="http-conneg"/>, this can be negotiated on the HTTP protocol level</li>
				</ul>
			</ul>
		</slide>
		<part id="xml">
			<title short="XML">Extensible Markup Language (XML)</title>
			<slide>
				<title>XML Use Cases</title>
				<ul>
					<li>XML is a metalanguage supporting application-specific vocabularies</li>
					<li><link href="syndication">RSS and Atom</link> are XML vocabularies for newsfeeds</li>
					<ul>
						<li><a href="http://docordie.blogspot.com/">Doc or Die</a>: <a href="http://docordie.blogspot.com/rss.xml">RSS feed</a> vs. <a href="http://docordie.blogspot.com/atom.xml">Atom feed</a></li>
						<li>browsers now incorporate and/or integrate newsfeed readers</li>
					</ul>
					<li><em>OpenDocument (ODF)</em> is a language for office application documents</li>
					<ul>
						<li>designed for open and interoperable exchange</li>
						<li>standardized by ISO (which now also standardizes Microsoft's <em>Open XML</em>)</li>
					</ul>
					<li><em>Scalable Vector Graphics (SVG)</em> for portable vector graphics</li>
					<ul>
						<li>designed for embedding in Web pages</li>
						<li>good example for compound documents: <a href="http://www.carto.net/papers/svg/animated_weather_symbols/">HTML containing SVG</a></li>
					</ul>
					<li>XML also can be used for representing complex structured documents</li>
				</ul>
			</slide>
			<slide>
				<title>Markup?</title>
				<ul>
					<li>Structures are encoded using special characters</li>
					<ul>
						<li>a fundamental difference in comparison to binary formats</li>
						<li>markup languages can be read and modified using text-based tools</li>
						<li>programs must treat markup characters in a special way</li>
					</ul>
					<li>Documents are content interspersed with markup (i.e., structures)</li>
					<ul>
						<li>XML-aware software interprets the markup</li>
						<li>XML-unaware software just sees a text file</li>
						<li>modifications must be made XML-aware (e.g., inserting <q>AT&amp;T</q> as <q>AT&amp;amp;T</q>)</li>
					</ul>
					<li>You have to pay the <link href="markup-price"/></li>
					<li>You need a <em>parser</em> for interpreting the markup</li>
				</ul>
			</slide>
			<slide>
				<title>Basic Concepts</title>
				<ul>
					<li>XML Documents have an <em>XML declaration</em> (optional)</li>
					<li>There is exactly one <em>document element</em> (a.k.a. <em>root element</em>)</li>
					<li>Elements may be nested (there is no conceptual limit)</li>
					<ul>
						<li>elements may be repeated (they can be identified by position)</li>
					</ul>
					<li>Elements are marked up using <em>tags</em></li>
					<ul>
						<li>most elements have content, surrounded by <em>start tags</em> and <em>end tags</em></li>
						<li>empty elements are allowed and may use a special notation</li>
					</ul>
					<li>Elements may have attributes (zero to any number)</li>
					<ul>
						<li>attributes can only occur once on an element (i.e., they cannot be repeated)</li>
					</ul>
				</ul>
				<listing src="my-first.xml"/>
			</slide>
			<slide id="xmltree">
				<title>Tree Syntax</title>
				<ul>
					<li>Markup is important, but only a notation</li>
					<li>XML documents are trees with different node types</li>
					<ul>
						<li>nodes so far: document, element, attribute, text</li>
					</ul>
					<img style="width : 90% ; margin : 4% ;" src="document-tree.png" title="XML document tree"/>
				</ul>
			</slide>
			<slide id="xmlelements">
				<title>Elements</title>
				<ul>
					<li>Elements can use a <a href="http://www.w3.org/TR/xml/#NT-Name">wide variety of names</a></li>
					<ul>
						<li>Allowed: <elem>html</elem>, <elem>id9832798472</elem>, <elem>_</elem>, <elem>:</elem>, <elem>こんにちは</elem></li>
						<li>Disallowed: leading numbers, spaces, control characters</li>
					</ul>
					<li>Element names usually convey some information about the content</li>
					<ul>
						<li>this is not reliable and highly language-dependent</li>
						<li>it is <em>very useful</em> when working with a known vocabulary</li>
						<li>it is <em>potentially harmful</em> when working with an unknown vocabulary</li>
					</ul>
					<li>Elements are the foundation for XML's versatility</li>
					<ul>
						<li>they can be nested (<code>&lt;address>&lt;city>Berkeley&lt;/city>&lt;zip>94720&lt;/zip>…</code>)</li>
						<li>they can be repeated (<code>&lt;givenname>Erik&lt;/givenname>&lt;givenname>Thomas&lt;/givenname></code>)</li>
						<li>their sequence can convey additional information (given names have a sequence)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Attributes</title>
				<ul>
					<li>Additional information pertaining to elements</li>
					<li>Traditionally, anything that is not considered <q>content</q></li>
					<ul>
						<li>SGML is a document markup language</li>
						<li>XML uses SGML's concepts</li>
						<li>XML has its roots in the document world</li>
					</ul>
					<li>Elements: Content (i.e., Data); Attributes: Metadata</li>
					<li>Documents often distinguish by what is textual content</li>
				</ul>
				<listing src="section.xml" line="12-20"/>
			</slide>
			<slide>
				<title>Attribute Syntax</title>
				<ul>
					<li>Naming rules are the same as for <link href="xmlelements"/></li>
					<li>Attributes always appear within an element's <em>start tag</em></li>
					<li>Attributes are <a href="http://www.w3.org/TR/xml/#NT-Attribute">name/value-pairs</a></li>
					<ul>
						<li>the value is enclosed in single or double quotes</li>
					</ul>
					<li>Attribute with a single-quote value: <elem>elem attr="Single: '"/</elem></li>
					<li>Attribute with a double-quote value: <elem>elem attr='Double :"'/</elem></li>
					<li>How can attribute values contain both?</li>
				</ul>
			</slide>
			<slide id="markup-price">
				<title>The Price for Markup</title>
				<ul>
					<li>Markup characters have a special meaning</li>
					<ul>
						<li><q>&lt;</q> opens a tag</li>
						<li>for attribute values, quotes delimit the value</li>
					</ul>
					<li>The literal use of a markup character requires escaping</li>
					<ul>
						<li>XML's <em>entities</em> can refer to pieces of content</li>
						<li>entity syntax is <code>&amp;name;</code> for referring to the entity <q><code>name</code></q></li>
						<li>XML has 5 <a href="http://www.w3.org/TR/xml/#sec-predefined-ent">predefined entities</a>: <code>&amp;lt;</code>, <code>&amp;gt;</code>, <code>&amp;amp;</code>, <code>&amp;apos;</code>, <code>&amp;quot;</code></li>
					</ul>
					<li>Attribute using both kinds of quotes: <code>&lt;elem attr="Single ' and Double &amp;quot;"/></code></li>
				</ul>
				<pre><![CDATA[<li>Attribute using both kinds of quotes: <code>&lt;elem attr="Single ' and Double &amp;quot;"/></code></li>]]></pre>
			</slide>
		</part>	
		<part id="json">
			<title short="JSON">JavaScript Object Notation (JSON)</title>
			<slide>
				<title>XML Example</title>
				<listing src="mobapp2010.atom" line="2-29" href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=rss_200"/>
			</slide>
			<slide>
				<title>JSON Example</title>
				<listing src="mobapp2010.json" line="1-22" href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=json"/>
			</slide>
			<slide>
				<title>Object Notation</title>
				<ul>
					<li>Uses a subset of JavaScript syntax (static data structures)</li>
					<li>Data model is derived from JavaScript's data model</li>
					<ul>
						<li>number, string, and boolean for simple values</li>
						<li>objects represents sets of values (using curly braces)</li>
						<li>arrays represent sequences of values (using square brackets)</li>
						<li><em>null</em> as a special value</li>
					</ul>
					<li>Based on JavaScript but usable in many languages</li>
					<ul>
						<li>can be readily mapped to the data models of many programming languages</li>
						<li>XML is not native in any major programming language (research: <a href="http://en.wikipedia.org/wiki/ECMAScript_for_XML">E4X</a>/<a href="http://www.alphaworks.ibm.com/tech/xj">XJ</a>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>JSON via URI Parameter</title>
				<ul>
					<li>Many services provide structured data in various formats</li>
					<ul>
						<li>logically speaking these are just different representations of the same content</li>
						<li>depending on trends and technologies, new formats may be added</li>
					</ul>
					<li>URIs allow <em>query strings</em> for transmitting data <q>to</q> a resource</li>
					<ul>
						<li><a href="../web-fall09/forms">HTML forms</a> use query strings for submitting form values</li>
					</ul>
					<li>Query strings can also be used <q>manually</q> in a URI</li>
					<ul>
						<li><q>hackable</q> URIs are convenient for developers</li>
					</ul>
					<li><code><a href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=rss_200">http://api.flickr…1313291@N20&amp;lang=en-us&amp;format=rss_200</a></code></li>
				</ul>
			</slide>
			<slide>
				<title>JSON via Content Negotiation</title>
				<ul>
					<li>XML or JSON are just different representations</li>
					<ul>
						<li>they represent the same underlying resource (as identified by the URI)</li>
					</ul>
					<li><link href="http-conneg"/> allows to specify preferences</li>
					<ul>
						<li>clients specify preferences and server respond with the best match</li>
					</ul>
					<li> HTTP <http>Accept</http> specifies the accepted <a href="../web-fall09/mediatypes">media type</a></li>
					<ul>
						<li>resources may be available in HTML, XML, or JSON</li>
						<li>depending on the HTTP request, the server responds with the best representation</li>
						<li>reduces processing time on the client and can be cached</li>
					</ul>
					<li>Really smart Ajax frameworks could even hide the content negotiation</li>
					<ul>
						<li>request JSON or XML, with XML being the lower priority</li>
						<li>if XML is sent by the server, it has to be parsed into a JavaScript object</li>
						<li>the end result is always a JavaScript object for the framework user</li>
					</ul>
				</ul>
			</slide>
		</part>	
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>Many applications need service access</li>
				<li>Most applications need access to structured data</li>
				<li>XML is a flexible format for representing structured data</li>
				<li>JSON is a little less flexible but easier to use</li>
				<li>JavaScript code is much easier to write for JSON services</li>
			</ul>
		</slide>
	</presentation>
	<presentation id="syndication">
		<title short="Syndication">Content Syndication</title>
		<date>2010-02-10</date>
		<toc class="reading"></toc>
		<toc class="resources"><a href="http://tools.ietf.org/html/rfc4287" title="Atom RFC">Atom</a>&#160;· <a href="http://tools.ietf.org/html/rfc5023" title="Atom Publishing Protocol (\) RFC">AtomPub</a>&#160;· <a href="http://validator.w3.org/feed/" title="W3C RSS/Atom Feed Validator">Validator</a>&#160;· <a href="http://www.xml.com/pub/a/2004/08/18/pilgrim.html">Identifying Atom</a></toc>
		<toc class="abstract">For many information sources on the Web, it is useful to have some standardized way of subscribing to information updates. Syndication formats such as  <em>RSS</em> and <em>Atom</em> can be used by these information sources to publish a <em>feed</em> of updated information items. Extensions allow feeds to carry additional data, for example in <em>podcasts</em>. While RSS and Atom are read-only formats, the <em>Atom Publishing Protocol (AtomPub)</em> build on top of Atom and provides a protocol for submitting new items to feeds.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Content Feeds</title>
			<ul>
				<li>Early Web content was static or updated very infrequently</li>
				<ul>
					<li>there was not yet the requirement to reuse content in different contexts</li>
				</ul>
				<li>Frequently updated Web content quickly became a very common scenario</li>
				<ul>
					<li>as commercial interests took over the Web, users should have a reason to re-visit a site</li>
					<li>presenting a steady stream of new content creates the image of a live Web site</li>
				</ul>
				<li>There are two major use cases where HTML is not sufficient</li>
				<ol>
					<li>users want an efficient way to get the updated content from a site</li>
					<li>sites want to aggregate updated content from other sites and re-publish it</li>
				</ol>
				<li><link href="syndication-formats"/> are designed to support these two use cases</li>
				<ul>
					<li>container formats for updated items</li>
					<li>a small amount of metadata about these items for automated processing</li>
				</ul>
			</ul>
		</slide>
		<part id="syndication-formats">
			<title>Syndication Formats</title>
			<part id="rss">
				<title>RSS</title>
				<slide id="rss-versions">
					<title>RSS History</title>
					<ul>
						<li><q><a href="http://diveintomark.org/archives/2004/02/04/incompatible-rss">The Myth of RSS Compatibility</a></q> provides a good overview</li>
						<li>RSS is a schoolbook example for <q>why standards are a good thing</q></li>
						<ul>
							<li>RSS 0.9 was created for the <em>My Netscape</em> portal in March 1999</li>
							<li>RSS 0.91 (a simplification) was introduced in July 1999 (as an interim solution)</li>
							<li>the AOL/Netscape merger removed the format from the company's portal</li>
							<li>RSS was without an owner, and different parties claimed/denied ownership</li>
							<li>RSS 1.0 was created by an informal developer group</li>
							<li>RSS 0.92 (and 0.93 and 0.94) were published without acknowledging RSS 1.0</li>
							<li>finally, RSS 2.0 was released as a follow-up to the RSS 0.9x versions</li>
						</ul>
						<li>Using RSS has become an exercise in managing a menagerie of versions</li>
					</ul>
				</slide>
				<slide>
					<title>RSS 2.0 Example</title>
					<listing src="mobapp2010.rss" line="2-32" href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=rss_200"/>
				</slide>
				<slide>
					<title>Podcast Example</title>
					<listing src="ted-talks.rss" line="2-71" href="http://feeds.feedburner.com/TEDTalks_video"/>
				</slide>
				<slide>
					<title>The Case for Content Management</title>
					<ul>
						<li>RSS is very rarely produced by hand</li>
						<ul>
							<li>by definition, RSS contains redundant information for a specific purpose</li>
						</ul>
						<li>If a <a href="../web-fall09/cms">Content Management System (CMS)</a> is used, RSS can be generated</li>
						<ul>
							<li>basic metadata can be generated by the CMS (title, author, date)</li>
							<li>better tagging of content results in better tagging of feeds</li>
							<li>well-tagged feeds are better foundations for large-scale reuse of feed items</li>
						</ul>
						<li>Blogging is simply a specialized case of a CMS</li>
						<ul>
							<li>Web-based interface for controlling everything</li>
							<li>strictly time-ordered sequenced of published items</li>
							<li>navigation features primarily based on the time-specific facets of the blog (maybe tags)</li>
							<li>all blogging tools include feed support</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Consuming RSS</title>
					<ul>
						<li>RSS feeds often have quality problems</li>
						<ul>
							<li>surprisingly often feeds do not even deliver well-formed XML</li>
							<li>the use of embedded markup in RSS is not well-defined</li>
						</ul>
						<li>Writing an RSS reader from scratch is not a good idea</li>
						<li>There are three major tasks which RSS readers must do</li>
						<ol>
							<li>accept non-XML RSS feeds and fix them to be XML</li>
							<li>look at the feed contents and bring them into a unified form</li>
							<li>produce a unified view of feeds regardless of the RSS version</li>
						</ol>
					</ul>
				</slide>
				<slide>
					<title>RSS Political Problems</title>
					<ul>
						<li>Multiple and incompatible <link href="rss-versions"/> are still in widespread use</li>
						<ul>
							<li>RSS 1.0 and RSS 2.0 are <q>incompatible by design</q> (RDF vs. non-RDF)</li>
							<li>none of the RSS versions is maintained by a universally accepted standards body</li>
						</ul>
						<li>None of the specifications is being updated or fixed</li>
						<ul>
							<li>some of the lessons learned by RSS deployment are not used in a new version</li>
							<li>it is unlikely that a new version will be produced which merges the RSS landscape</li>
						</ul>
						<li>Invent something new instead of trying to fix RSS</li>
						<ul>
							<li><link href="atom"/> started in 2003 (called <em>Echo</em> at first)</li>
							<li>W3C or IETF would have been promising candidates for a <q>new RSS</q></li>
							<li>W3C is more formal, IETF is more developer-centered</li>
							<li><a href="http://www.bestkungfu.com/?p=492">IETF was chosen over W3C</a> because the of Atom community's preferences</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="atom">
				<title>Atom</title>
				<slide>
					<title>Atom History</title>
					<img src="atom-logo.png" href="http://atompub.org/" style="float : right ; width : 20% ; margin-top : 0.5em ; margin-right : 2em ; "/>
					<ul>
						<li>RSS's shortcomings were very apparent and could not be fixed</li>
						<li>In mid-2003, discussions started about an improved format</li>
						<li>It also became apparent that the format should have a protocol</li>
						<li>Atom 0.3 was released in December 2003 but had no formal home</li>
						<li>IETF was chosen as the new home with a working group in June 2004</li>
						<li><a href="http://tools.ietf.org/html/rfc4287">RFC 4287</a> was published in December 2005</li>
						<li><link href="atompub">AtomPub</link> has been published as <a href="http://tools.ietf.org/html/rfc5023">RFC 5023</a> in October 2007</li>
					</ul>
				</slide>
				<slide>
					<title>Atom vs. RSS</title>
					<ul>
						<li>Standardized by the IETF (well-defined process)</li>
						<li>Classification of entries (user-defined categories)</li>
						<li>More XML-like markup design (more nesting)</li>
						<li>Namespaces are used and supported as standard mechanism</li>
						<li>Atom feeds <em>must</em> be well-formed XML (there even <a href="http://atompub.org/2005/08/17/atom.rnc" title="Atom RELAX NG Schema">is a schema</a>)</li>
						<li>Interpretation of content is well-defined (various content types)</li>
						<li>Support for <code>xml:lang</code> and <code>xml:base</code></li>
					</ul>
				</slide>
				<slide>
					<title>Atom Example</title>
					<listing src="mobapp2010.atom" line="2-29" href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=atom"/>
				</slide>
				<slide>
					<title>Atom Content</title>
					<ul>
						<li>RSS had no safe way of finding out what an entry's content is</li>
						<ul>
							<li>this led to different implementations being <q>smart</q> about what the RSS author really wanted</li>
							<li>one of Atom's main goals was to improve this in a well-defined way</li>
							<li>Atom allows escaped markup (the only way to include non-XML HTML in an XML format)</li>
						</ul>
						<li>Each <elem>content</elem> element should have a <atom>type</atom> (the default is <code>text</code>)</li>
						<li>Atom's content interpretation algorithm (use first applicable rule):</li>
						<ol>
							<li>if <atom>type</atom> is <code>text</code>, no child elements are allowed (plain text content)</li>
							<li>if <atom>type</atom> is <code>html</code> then RSS's method of escaped markup is used</li>
							<li>if <atom>type</atom> is <code>xhtml</code> then there must be an <elem>div</elem> containing XHTML markup</li>
							<li>if <atom>type</atom> is an XML <a href="../web-fall09/mediatypes">media type</a> then the content should be treated as this type</li>
							<li>if <atom>type</atom> starts with <code>text/</code> then no child elements are allowed</li>
							<li>for all other values, the content must be an base64-encoded entity of the specified MIME type</li>
						</ol>
					</ul>
				</slide>
				<slide>
					<title>Atom Content Examples</title>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
	One <strong>bold</strong> foot forward
  </div>
</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content>The "atom:content" element either contains or links to the content of the entry. The content of atom:content is Language-Sensitive.</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content type="html">The &lt;code>atom:content&lt;/code> element either contains or links to the content of the entry. The content of &lt;code>atom:content&lt;/code> is &lt;a href="http://www.ietf.org/rfc/rfc3066.txt">Language-Sensitive&lt;/a>.</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content type="image/png">
iVBORw0KGgoA … TAAAAAElFTkSuQmCC
</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content src="image.png" type="image/png"/>]]></pre>
				</slide>
			</part>
		</part>
		<part>
			<title>Syndication Aggregation</title>
			<slide>
				<title>End-User Aggregation</title>
				<img src="feed-icon.png" style="float : right ; margin-top : 0.5em ; margin-right : 2em ; "/>
				<ul>
					<li>Users often have a small number of preferred Web sites</li>
					<ul>
						<li>news can be tracked by subscribing to their feeds</li>
						<li>this requires an feed-aware client (Firefox is not a good feed reader)</li>
					</ul>
					<li>Ajax-based feeds could be implemented as a client-side application</li>
					<ul>
						<li>retrieve the feed, transform it to HTML, and render the result</li>
						<li>but the security restriction of <code>XMLHttpRequest</code> gets into the way</li>
						<li>there is a way around this as used in the <a href="http://www-128.ibm.com/developerworks/library/x-ajaxrss/" title="IBM developerWorks Article by Jack D. Herrington">Ajax RSS reader</a></li>
						<li><a href="http://www.google.com/reader/view/">Google Reader</a> accesses Google's own copy of the feed (<link href="feedburner"/>)</li>
					</ul>
					<li>How can users find a feed?</li>
					<ul>
						<li>feeds have URIs (they are Web resources) and can be referenced from within HTML</li>
					</ul>
				</ul>
				<pre title="Feed Autodiscovery for RSS">&lt;link rel="alternate" type="application/rdf+xml" title="…" href="…" />
&lt;link rel="alternate" type="application/rss+xml" title="…" href="…" /></pre>
				<pre title="Feed Autodiscovery for Atom">&lt;link rel="alternate" type="application/atom+xml" title="…" href="…" /></pre>
			</slide>
			<slide>
				<title>Aggregation Intermediaries</title>
				<div style="float : right ; width : 20% ; margin-right : 1.5em">
					<script type="text/javascript" src="http://www.google.com/reader/ui/publisher.js"></script>
					<script type="text/javascript" src="http://www.google.com/reader/public/javascript/user/16601496766743088901/state/com.google/broadcast?n=5&amp;callback=GRC_p(%7Bc%3A'gray'%2Ct%3A'Shared%20items'%2Cs%3A'true'%7D)%3Bnew%20GRC"></script>
				</div>
				<ul>
					<li>RSS is a frequently used format between content providers</li>
					<ul>
						<li>news agencies want to distribute news items as easy as possible</li>
						<li>by using a single format, producers and consumers can more easily interoperate</li>
					</ul>
					<li>The <link href="rss-versions"/> caused publishers to look for something better</li>
					<ul>
						<li><link href="rss"/> had a head start and still is widely used</li>
						<li><link href="atom"/> is a much better format and will eventually replace RSS</li>
					</ul>
					<li>User-configured portals are the merger between both scenarios</li>
					<ol>
						<li>users select a number of feeds as their preferred information sources</li>
						<li>the feeds are presented on a <a href="http://www.google.com/reader/view/" title="Google Reader">single personalized Web page</a></li>
						<li>by <a href="http://www.google.com/reader/shared/16601496766743088901" title="dret's Google Reader Shared Items">sharing</a> and <a href="http://www.google.com/reader/public/atom/user/16601496766743088901/state/com.google/broadcast" title="dret's Google Reader Atom Feed">re-publishing</a> items, users are becoming aggregation intermediaries</li>
					</ol>
				</ul>
			</slide>
			<part id="feedburner">
				<title>FeedBurner</title>
				<slide>
					<title>Fixing Feeds</title>
					<img style="width : 90% ; margin : 2% ; " src="feedburner-cleanup.png" title="Cleaning Up Feeds"/>
				</slide>
				<slide>
					<title>Load Balancing</title>
					<img style="width : 90% ; margin : 2% ; " src="feedburner-load-balancing.png" title="Providing Feed Load Balancing"/>
				</slide>
				<slide>
					<title>Statistics/Analytics</title>
					<img style="width : 90% ; margin : 2% ; " src="feedburner-statistics.png" title="Providing Feed Statistics"/>
				</slide>
			</part>
		</part>
		<part id="atompub">
			<title>Atom Publishing Protocol</title>
			<slide>
				<title>Syndication Format Protocols</title>
				<ul>
					<li>LiveJournal (very simple text-based protocol)</li>
					<ul>
						<li>not very good at handling structures (re-inventing for encoding structure)</li>
					</ul>
					<li>Blogger (now at <a href="http://code.google.com/apis/blogger/overview.html">Google</a> after <a href="http://web.archive.org/web/20031008161432/http://weblog.siliconvalley.com/column/dangillmor/archives/000802.shtml">Google bought Pyra</a>)</li>
					<ul>
						<li>no support for titles or any other sort of entry metadata</li>
						<li>protocol from the early days of blogging before tagging became popular</li>
					</ul>
					<li><a href="http://www.xmlrpc.com/metaWeblogApi">MetaWeblog</a> (an attempt to improve Blogger)</li>
					<ul>
						<li>extends Blogger using a very bad design (RSS XML as XML-RPC structure encoded as XML)</li>
					</ul>
					<li><em>Atom Publishing Protocol (AtomPub)</em> is an attempt to provide a clean alternative</li>
					<ul>
						<li>use the same document structures for feeds and the protocol interacting with them</li>
						<li>use a REST approach to provide a simple and Web-compatible protocol</li>
						<li>add <link href="atom-service-documents"/> and <link href="atom-category-documents"/> for additional tasks</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>RESTified Syndication</title>
				<ul>
					<li>Atom is a format for retrieving a set of entries as a feed document</li>
					<ul>
						<li>feeds often are time-based and are refreshed periodically or whenever needed</li>
						<li>feeds can use any other strategy for deciding what to publish</li>
					</ul>
					<li>Read-only access to feeds should be complemented by full access</li>
					<ul>
						<li>full access needs the <q>CUD</q> out of the <q>CRUD</q> set of operations</li>
						<li>many Web-centric technologies try to build on the Web's REST model of interaction</li>
					</ul>
					<li>AtomPub builds on Atom and adds a REST-based protocol on top of it</li>
					<ul>
						<li><http>POST</http> for creating new entries (sending the request to the collection)</li>
						<li><http>PUT</http> for updating existing entries (overwriting the existing entry)</li>
						<li><http>DELETE</http> for deleting entries from a collection</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Protocol Summary</title>
					<table border="1" cellpadding="20" style="width : 90% ; margin : 2% ; ">
						<thead>
							<tr valign="top">
								<th>Resource</th>
								<th>HTTP Method</th>
								<th>Representation</th>
								<th>Description</th>
							</tr>
						</thead>
						<tbody>
							<tr valign="top">
								<td>Introspection</td>
								<td>
									<http>GET</http>
								</td>
								<td><link href="atom-service-documents">Atom Service Document</link></td>
								<td>Enumerates a set of collections and lists their URIs and other information about the collections</td>
							</tr>
							<tr valign="top">
								<td>Collection</td>
								<td>
									<http>GET</http>
								</td>
								<td>Atom Feed</td>
								<td>A list of member of the collection (this may be a subset of all entries in the collection)</td>
							</tr>
							<tr valign="top">
								<td>Collection</td>
								<td>
									<http>POST</http>
								</td>
								<td>Atom Entry</td>
								<td>Create a new entry in the collection</td>
							</tr>
							<tr valign="top">
								<td>Member</td>
								<td>
									<http>GET</http>
								</td>
								<td>Atom Entry</td>
								<td>Get the Atom Entry</td>
							</tr>
							<tr valign="top">
								<td>Member</td>
								<td>
									<http>PUT</http>
								</td>
								<td>Atom Entry</td>
								<td>Update the Atom Entry</td>
							</tr>
							<tr valign="top">
								<td>Member</td>
								<td>
									<http>DELETE</http>
								</td>
								<td>n/a</td>
								<td>Delete the Atom Entry from the collection</td>
							</tr>
						</tbody>
					</table>
			</slide>
			<slide id="atom-service-documents">
				<title>Service Documents</title>
				<blockquote>Service Documents represent server-defined groups of Collections, and are used to initialize the process of creating and editing resources.</blockquote>
				<ul>
					<li>The <q>real</q> top-level construct of AtomPub is the <em>workspace</em></li>
					<ul>
						<li>collections on a server are organized into different workspaces</li>
						<li>workspaces have no AtomPub semantics and no operations can be performed on them</li>
					</ul>
					<li>Service documents list constraints on the members of collections</li>
					<ul>
						<li><atom>accept</atom> specifies a comma-separated list of media ranges (with <code>entry</code> as special value)</li>
						<li><atom>categories</atom> defines the list of categories that can be applied to members (can be <code>fixed</code>)</li>
						<li>AtomPub servers are likely to reject operations not satisfying these constraints</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Service Document Example</title>
				<listing src="atom-service.xml"/>
			</slide>
			<slide id="atom-category-documents">
				<title>Category Documents</title>
				<ul>
					<li>Categories are important for creating and reading entries</li>
					<ul>
						<li>they may contain metadata using any classification scheme</li>
					</ul>
					<li><link href="atom-service-documents"/> contain a list of allowed categories</li>
					<li>AtomPub defines a document format for standalone category documents</li>
					<ul>
						<li>a useful interface between AtomPub systems and other systems using classification schemes</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Category Document Example</title>
				<listing src="atom-category.xml"/>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Semantic Web Light</title>
				<ul>
					<li>Syndication creates representations for universal concepts</li>
					<li>Atom adds some concepts to RSS's model</li>
					<li>Syndication revolves around the idea of interacting with items</li>
					<li>Atom-based interaction is one way of implementing REST</li>
					<li>For more semantics, Atom is only the foundation</li>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="foundations">
		<title short="Foundations">Web Foundations (URI &amp; HTTP)</title>
		<date>2010-02-12</date>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/why_mobile" title="Mobile Design and Development; Chapter 3: Why Mobile?">Why Mobile?</a></toc>
		<toc class="resources"><a href="http://www.w3.org/Provider/Style/URI" title="Cool URIs don't change">Cool URIs</a>&#160;· <a href="https://addons.mozilla.org/en-US/firefox/addon/3829" title="Firefox Add-on: Live HTTP Headers">Live HTTP Headers</a>&#160;· <a href="http://tools.ietf.org/html/rfc3986" title="IETF RFC 3986: Uniform Resource Identifier (URI)">URI Spec</a>&#160;· <a href="http://tools.ietf.org/html/rfc2616" title="IETF RFC 2616: Hypertext Transfer Protocol (HTTP)">HTTP Spec</a></toc>
		<toc class="abstract">The Web's architecture has very simple principles revolving around the ideas of placing a heavy emphasis on a consistent and global identification mechanism for resources, a standardized way of how resource representations can be retrieved, and a standardized way of how resource representations should be usable by using standardized media types. Based on the Internet, the Web's transport protocol transmits representations of resources identified by a <em>Uniform Resource Identifier (URI)</em> between Web servers and clients. The most important protocols for data transfer on the Web is the <em>Hypertext Transfer Protocol (HTTP)</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="uri">
			<title short="URI">Uniform Resource Identifier (URI)</title>
			<slide>
				<title>Resource Identification</title>
				<ul>
					<li>The Web is centered around resources</li>
					<ul>
						<li>HTTP has been designed to manipulate resources</li>
						<li>HTTP provides methods for getting, putting, updating, and even deleting resources</li>
					</ul>
					<li>Resources are useful abstractions for interfaces</li>
					<ul>
						<li>instead of an API, interaction is built around manipulating resources</li>
						<li>APIs change and bind closely, documents can better withstand change and bind loosely</li>
						<li>the whole Web is built around resources, not APIs</li>
					</ul>
				</ul>
			</slide>
			<slide id="uri-schemes">
				<title>URI Schemes</title>
				<pre>URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]</pre>
				<pre>http://dret.net/lectures/web-fall09/foundations#uri-schemes</pre>
				<ul>
					<li>URIs in their general case are very simple</li>
					<ul>
						<li>the scheme identifies how resources are identified</li>
						<li>the identification may be hierarchical or non-hierarchical</li>
					</ul>
					<li>Many URI schemes are hierarchical</li>
					<ul>
						<li>it is then possible to use relative URIs such as in <htmel>a href="../"</htmel></li>
						<li>the slash character is not just a character, in URIs it has semantics</li>
					</ul>
					<li>Query components specify additional information</li>
					<ul>
						<li>it is non-hierarchical information further identifying the resource</li>
						<li>in most cases, it can be regarded as <q>input</q> to the resource</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="http">
			<title short="HTTP">Hypertext Transfer Protocol (HTTP)</title>
			<slide>
				<title>DNS &amp; HTTP</title>
				<p>The two basic protocols which every Web browser must implement are <em>DNS</em> access and <link href="http">HTTP</link>. However, most operating systems provide an API for DNS access, so the browser can use this service locally and only has to implement HTTP. <em>TCP</em> (which is required as the foundation for HTTP) is usually provided by the operating system.</p>
				<img style="width : 90% ; margin : 2% ; " src="browser-dns-http.png"/>
			</slide>
			<slide>
				<title>The Web's Protocol</title>
				<img style="height : 60% ; margin : 4% ; float : left ; " src="internet-traffic-trends.png"/>
				<p class="quotenote">provided by <a href="http://www.cachelogic.com/">CacheLogic Inc.</a></p>
			</slide>
			<part>
				<title>HTTP Basics</title>
				<slide>
					<title>HTTP Messages</title>
					<ul>
						<li>HTTP needs a reliable connection</li>
						<ul>
							<li>the foundation for HTTP is <em>TCP</em></li>
							<li>DNS resolution yields an <link href="ip-address">IP address</link></li>
							<li>open TCP connection to port 80 or port specified in URI (<code>http://rosetta.ischool.berkeley.edu:8085/</code>)</li>
						</ul>
						<li>HTTP is a <em>text-based</em> protocol</li>
						<ul>
							<li>the connection is used to transmit <em>text messages</em></li>
							<li>all HTTP messages are human-readable (not all <em>entities</em>, though)</li>
							<li>basic HTTP operations can be carried out by hand</li>
						</ul>
					</ul>
<pre>start-line
message-header *

message-body ?</pre>
				</slide>
				<slide id="http-headers">
					<title>HTTP Header Fields</title>
					<ul>
						<li>Header fields contain information about the message</li>
						<ul>
							<li><em>general header:</em> <code>Date</code> as the message origination date</li>
							<li><em>request header:</em> <code>Accept-Language</code> indicates language preferences</li>
							<li><em>response header:</em> <code>Server</code> contains system information</li>
							<li><em>entity header:</em> <code>Content-Type</code> specifies the media type of the entity</li>
						</ul>
						<li>HTTP defines <a href="http://www.cs.tut.fi/~jkorpela/http.html">a number of header fields</a></li>
						<ul>
							<li>unknown fields must be ignored (extensibility)</li>
							<li>unstandardized fields should use a <q><code>X-</code></q> prefix</li>
						</ul>
						<li>HTTP is about acting on these fields</li>
						<ul>
							<li>HTTP defines what HTTP implementations must or should do</li>
						</ul>
					</ul>
				</slide>
				<slide id="http-conneg">
					<title>HTTP Content Negotiation</title>
					<ul>
						<li><link href="http-headers"/> have interaction semantics</li>
						<ul>
							<li>depending on the <q>header type</q> they convey different information</li>
						</ul>
						<li><em href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html">HTTP Content Negotiation</em> allows representation negotiation</li>
						<ul>
							<li>the client specifies a number of preferred content properties</li>
							<li>the server responds with the representation that <q>fits best</q></li>
						</ul>
						<li><em>Server-driven negotiation</em> can use a number of request header fields</li>
						<ul>
							<li><code>Accept</code> uses a list of <a href="../web-fall09/mediatypes">media types</a></li>
							<li><code>Accept-Charset</code> uses a list of character sets</li>
							<li><code>Accept-Encoding</code> uses a list of content encodings</li>
							<li><code>Accept-Language</code> uses a list of language codes</li>
							<li><code>User-Agent</code> specifies the client's identification</li>
						</ul>
						<li><em>Client-driven negotiation</em> lets the server send a list of URIs</li>
						<ul>
							<li>two steps are required to get the best alternate representation</li>
						</ul>
					</ul>
				</slide>
				<slide id="http-request">
					<title>HTTP Requests</title>
					<ul>
						<li>After opening a connection, the client sends a request</li>
						<ul>
							<li>the method indicates the action to be performed on the resource</li>
							<li>HTTP's most interesting methods are: <code>GET</code>, <code>HEAD</code>, <code>POST</code></li>
							<li>other interesting methods are: <code>PUT</code>, <code>DELETE</code></li>
						</ul>
						<li>The URI identifies the resource to which the request should be applied</li>
						<ul>
							<li>absolute URIs are required when contacting <em>proxies</em></li>
							<li>absolute paths are required when contacting a server directly</li>
							<li>the URI may contain <em>query information</em></li>
						</ul>
						<li>The <code>Host</code> header field must be included in every request</li>
					</ul>
<pre>Method Request-URI HTTP/Major.Minor
[Header]*

[Entity]?</pre>
				</slide>
				<slide id="http-get">
					<title>HTTP GET</title>
					<ul>
						<li>Retrieval action based on the URI</li>
						<ul>
							<li>maybe implemented by reading a file</li>
							<li>maybe implemented by processing a file (PHP)</li>
							<li>maybe implemented by invoking a process</li>
						</ul>
						<li>Semantics may change based on header fields</li>
						<ul>
							<li><code>If-*:</code> only reply with the entity if necessary</li>
							<li><code>Range:</code> only reply with the requested part of the entity</li>
						</ul>
						<li>Cacheability depends on header fields of the response</li>
					</ul>
<pre>GET / HTTP/1.1
Host: ischool.berkeley.edu</pre>
				</slide>
				<slide id="http-response">
					<title>HTTP Responses</title>
					<ul>
						<li>The server's response to interpreting a request</li>
						<ul>
							<li>the status code is given numerically and as text</li>
							<li><code>2**</code> for variations of <q>ok</q></li>
							<li><code>3**</code> for redirections</li>
							<li><code>4**</code> are different client side problems (<code>404</code>: not found)</li>
							<li><code>5**</code> are different server side problems</li>
						</ul>
						<li>Header fields specify additional information</li>
						<ul>
							<li>information about the server</li>
							<li>information about the entity (media type, encoding, language)</li>
						</ul>
					</ul>
<pre>HTTP/Major.Minor Status-Code Text
[Header]*

[Entity]?</pre>
				</slide>
				<slide id="http-performance">
					<title>HTTP Performance</title>
					<ul>
						<li>HTTP/1.0 allowed one transaction per connection</li>
						<ul>
							<li>TCP connection setup and teardown are expensive</li>
							<li>TCP's <em>slow start</em> slows down the initial phase of data transfer</li>
							<li>typical Web pages use between 10-20 resources (HTML + images + CSS + scripts)</li>
							<li>typically, these resources are stored on the same server</li>
						</ul>
						<li>HTTP/1.1 introduces <em>persistent connections</em></li>
						<ul>
							<li>the TCP connection stays open for some time (10 sec is a popular choice)</li>
							<li>additional requests to the same server use the same TCP connection</li>
						</ul>
						<li>HTTP/1.1 introduces <em>pipelined connections</em></li>
						<ul>
							<li>instead of waiting for a response, requests can be queued</li>
							<li>the server responds as fast as possible</li>
							<li>the order may not be changed (there is no sequence number)</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>HTTP Connection Handling</title>
					<img style="width : 90% ; margin : 2% ; " src="http-phttp-pipelining.png"/>
				</slide>
			</part>
			<part id="http-authentication">
				<title>HTTP Authentication</title>
				<slide>
					<title>HTTP Access Control</title>
					<ul>
						<li>HTTP servers can <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error">deny access</a> through access control</li>
						<ul>
							<li><code>401 Unauthorized</code> means the resource is access controlled</li>
							<li><code>403 Forbidden</code> means the resource is inaccessible</li>
							<li><code>405 Method Not Allowed</code> signals a request using the wrong <link href="http-request">request method</link></li>
						</ul>
						<li>Two different approaches to unauthorized access are possible</li>
						<ul>
							<li>repeat the HTTP request with the proper authentication credentials</li>
							<li>redirect to a <link href="login-page"/> and establish an authenticated <em>session</em></li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>HTTP Authentication</title>
					<img style="width : 90% ; margin : 2% ; " src="authentication-http.gif" title="HTTP Authentication" href="http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html"/>
				</slide>
				<slide id="http-basic">
					<title>Basic HTTP Authentication</title>
					<ul>
						<li>Authentication is based on <em>authentication realms</em></li>
						<ul>
							<li>a set of resources for which the authentication is required</li>
							<li>an opaque name which is used to signal which login is required</li>
							<li>username/password often is specific for a given realm</li>
						</ul>
						<li>Users supply username and password through the client</li>
						<ul>
							<li>sent as <a href="http://en.wikipedia.org/wiki/Base64">Base64</a> encoded <q><code>username:password</code></q> string</li>
							<li>username and password are <a href="http://www.google.com/search?hl=en&amp;q=base64+decoder"><em>not</em> transmitted securely</a></li>
							<li>basic authentication should <em>always</em> use <link href="https">HTTPS</link></li>
						</ul>
						<li>Authorization is handled on the server side</li>
						<pre href="http://en.wikipedia.org/wiki/Basic_access_authentication">HTTP/1.0 401 Unauthorized
	WWW-Authenticate: Basic realm="SokEvo"</pre>
						<pre href="http://en.wikipedia.org/wiki/Basic_access_authentication">GET /private/index.html HTTP/1.0
	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==</pre>
					</ul>
				</slide>
				<slide>
					<title>Repeated Access</title>
					<ul>
						<li>Clients typically access more than one protected resource</li>
						<ul>
							<li>a perfectly stateless client would always request authentication from the user</li>
							<li>using the <em>realm</em> clients can identify repeated accesses</li>
						</ul>
						<li>Web interactions by default are perfectly stateless</li>
						<ul>
							<li>each request is completely independent from other requests</li>
							<li>stateless interactions make the Web loosely coupled and scalable</li>
							<li>concepts like the <em>realm</em> or <em>cookies</em> introduce <q>state</q></li>
						</ul>
						<li>Clients remember the authentication and replay it automatically</li>
						<ul>
							<li>browsers provide little control over this feature</li>
							<li><q>logging out</q> of HTTP authenticated sessions is hard</li>
						</ul>
					</ul>
				</slide>
				<slide id="login-page">
					<title>Login Page</title>
					<ul>
						<li><link href="http-basic"/> works with browser controls (including the window)</li>
						<ul>
							<li>no possibility to <q>log out</q> without using browser-specific controls</li>
							<li>client side security depends on browser security measures</li>
						</ul>
						<li>Using <em>HTML forms</em> gives more freedom in session management</li>
						<ul>
							<li><em>authentication</em> and <em>authorization</em> are completely application-based</li>
							<li>if there were <q>secure personal browsers</q> this would not work very well</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>HTTP is much more than file transfer</li>
				<ul>
					<li>it is a protocol for the concept of <em>resource manipulation</em></li>
					<li>it is a distinct step away from the <em>API approach</em> to building distributed systems</li>
				</ul>
				<li>HTTP servers can be configured to deliver good or bad service</li>
				<ul>
					<li>this is a question of how well they are configured on the HTTP level</li>
					<li>it is also a question of how good the Web design is</li>
					<li>both issues together are required to set up a good Web server</li>
				</ul>
			</ul>
		</slide>
	</presentation>
	<presentation id="ajax">
		<title short="Ajax">Scripting with Server Access</title>
		<date>2010-02-17</date>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/the_mobile_ecosystem" title="Building iPhone Apps with HTML, CSS, and JavaScript; Chapter 4: Animation">Animation with jQTouch</a></toc>
		<toc class="resources"><a href="http://www.yourhtmlsource.com/javascript/dhtmlexplained.html" title="DHTML Explained">DHTML</a>&#160;· <a href="http://en.wikipedia.org/wiki/Dynamic_HTML" title="Wikipedia: Dynamic HTML (DHTML)">Wikipedia</a>&#160;· <a href="http://www.w3.org/TR/XMLHttpRequest/" title="W3C: XMLHttpRequest"><code>XMLHttpRequest</code> Spec</a></toc>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Environment Setup">A3: Touch App</a> (assigned: 2/17; due: 3/1)</toc>
		<toc class="abstract">Scripting is used on the majority of today's modern Web sites. Scripting can be used to improve the usability and accessibility of a Web site (for example for <em>validating form data on the client side</em>), it can vastly improve the user experience with new interface design (the <em>smooth scrolling of Google Maps</em> vs. older <q>click to scroll</q> map services), or it can be used to implement behavior that would be impossible without scripting (for example the <em>online applications of Google Docs</em>). <em>Asynchronous JavaScript and XML (Ajax)</em> takes <em>Dynamic HTML (DHTML)</em> to the next level by allowing server access from within scripting code. This is accomplished by using a standardized API for client/server communications, the <code>XMLHttpRequest</code> object. This objects allows using HTTP connections from within scripting code, and thereby allows scripting code to dynamically reload data from a server in response to user interactions.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Current Events</title>
			<slide>
				<title>MeeGo = Maemo + Moblin</title>
				<img src="meego.jpg" style="height : 65% ; margin : 4% ; " href="http://www.ubergizmo.com/15/archives/2010/02/nokia_and_intel_announce_meego.html"/>
			</slide>
			<slide>
				<title>RIM goes WebKit</title>
				<img src="torch-acid.jpg" style="height : 65% ; margin : 4% ; " href="http://www.betanews.com/article/A-BlackBerry-browser-with-a-100-Acid3-score-RIM-finally-picks-up-the-Torch/1266342783"/>
			</slide>
		</part>
		<part>
			<title>Web App Development</title>
			<slide>
				<title>Scripting on the Web</title>
				<ul>
					<li>Early Web pages were static HTML</li>
					<ul>
						<li><a href="../web-fall09/forms">HTML forms</a> were the only interactive part of Web pages</li>
						<li>interaction was only possible by clicking links and visiting new pages</li>
						<li>CSS introduced limited dynamic behavior (such as <code>mouseOver</code> events)</li>
					</ul>
					<li>Netscape invented the <link href="dom"/> and <em>LiveScript</em></li>
					<ul>
						<li><a href="http://en.wikipedia.org/wiki/Java_(programming_language)">Java</a> was new and hip, so the language was renamed to <em>JavaScript</em></li>
						<li>pages with scripting (a.k.a. <em>Dynamic HTML</em> or <em>DHTML</em>) allowed richer user interfaces</li>
						<li>other browsers invented their own <q>versions</q> of DOM/JavaScript</li>
					</ul>
					<li>Scripting was and is often used to implement <q>missing functionality</q></li>
					<ul>
						<li>good scripting supports graceful degradation (leaving the page functional)</li>
						<li>bad scripting compromises accessibility when the scripting code does not work</li>
					</ul>
					<li>Any non-trivial scripting has to deal with browser differences</li>
					<ul>
						<li><link href="js-frameworks"/> help by providing a foundation to build on</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>The Joys of Web Design</title>
				<img style="height : 75% ; margin : 2% ; " src="web-design.png" title="Time Breakdown of Modern Web Design" href="http://www.poisonedminds.com/"/>
			</slide>
		</part>
		<part id="ajax-mechanics">
			<title>Ajax Mechanics</title>
			<slide>
				<title>Misleading Name</title>
				<ul>
					<li>All parts of the <q><code>XMLHttpRequest</code></q> name are misleading</li>
					<li><em>XML</em> sounds as if it can only handle XML transfers</li>
					<ul>
						<li>supports any payload (as long as it is text-based)</li>
						<li>XML is special because it is automatically parsed into a DOM</li>
					</ul>
					<li><em>HTTP</em> sounds as if it always uses HTTP</li>
					<ul>
						<li>all major implementations also support <link href="https">HTTPS</link></li>
						<li>some implementations even support protocols beyond HTTP(S)</li>
					</ul>
					<li><em>Request</em> sounds as it is only covering requests</li>
					<ul>
						<li>HTTP interactions are request/response exchanges</li>
						<li><code>XMLHttpRequest</code> handles all HTTP interaction mechanics</li>
					</ul>
					<li><code>XMLHttpRequest</code> essentially is a <em>client-side HTTP API</em></li>
				</ul>
			</slide>
			<slide>
				<title>Minimal <code>XMLHttpRequest</code> Example</title>
				<listing src="xmlhttprequest.html"/>
				<listing src="helloworld.xml"/>
			</slide>
			<slide>
				<title>HTTP Interactions</title>
				<ul>
					<li>HTTP has various <link href="http-request">request methods</link></li>
					<ul>
						<li><http>GET</http> is used for the vast majority of Web requests</li>
						<li>other methods allow to make changes on the server</li>
					</ul>
					<li><code>XMLHttpRequest</code> allows all HTTP methods to be used</li>
					<ul>
						<li>good support for servers implementing RESTful interfaces</li>
						<li>it is possible to <http>GET</http>, <http>PUT</http>, <http>POST</http>, and <http>DELETE</http> resources</li>
					</ul>
					<li>Despite its name, <code>XMLHttpRequest</code> can be used for any content type</li>
					<ul>
						<li>XML is just a special case and has some extra support</li>
						<li>any other content can be used as long as it is text-based</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Handling <code>XMLHttpRequest</code> Responses</title>
				<ul>
					<li>HTTP responses always have a media type</li>
					<ul>
						<li>the server indicates the media type of the response content</li>
						<li>the client can process the response according to that type</li>
					</ul>
					<li><code>responseText</code> always contains the entity body of the HTTP response</li>
					<li><code>XMLHttpRequest</code> treats XML-oriented responses in a special way</li>
					<ul>
						<li><code>text/xml</code>, <code>application/xml</code> or <code>…+xml</code> responses are XML media types</li>
						<li>XML media types are recognized and processed</li>
					</ul>
					<li><code>responseXML</code> contains XML parsed into a DOM tree</li>
					<ul>
						<li>DOM trees allow DOM-based navigation</li>
						<li>DOM tree navigation is not the most convenient way of navigating structured data</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Inspecting <code>XMLHttpRequest</code> Responses</title>
				<ul>
					<li><code>XMLHttpRequest</code> allows all header fields to be inspected</li>
					<ul>
						<li><code>getResponseHeader()</code> returns a specific response header</li>
						<li><code>getAllResponseHeaders()</code> returns all response headers</li>
					</ul>
				</ul>
				<pre>// The following script:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
	if(this.readyState == 2) {
		print(client.getResponseHeader("Content-Type"));
	}
}

// ...should output something similar to the following text:
Content-Type: text/plain; charset=utf-8</pre>
			</slide>
			<slide>
				<title>Requesting <code>XMLHttpRequest</code> Responses</title>
				<ul>
					<li>HTTP allows <em>content negotiation</em></li>
					<ul>
						<li>the can specify list of supported/preferred media types</li>
						<li>the server responds with the <q>best match</q></li>
					</ul>
					<li>XML/JSON can be distinguished by URI or by media type</li>
					<ul>
						<li>URI requires different <q>addresses</q> to be used in request</li>
						<li>media type requires the type to be specifically requested</li>
					</ul>
				</ul>
				<pre>// The following script:
var client = new XMLHttpRequest();
client.open('GET', 'ajax-data');
client.setRequestHeader('Accept', 'application/json;q=1.0, application/xml;q=0.8');
client.send();

// ... results in the following header being sent:
...
Accept: application/json;q=1.0, application/xml;q=0.8
...</pre>
			</slide>
			<slide>
				<title>Using XML Structures</title>
				<listing src="menu-xml.js" href="http://www.25hoursaday.com/weblog/2007/01/02/JSONVsXMLBrowserProgrammingModels.aspx"/>
			</slide>
			<slide>
				<title>Using JSON Structures</title>
				<listing src="menu-json.js" href="http://www.25hoursaday.com/weblog/2007/01/02/JSONVsXMLBrowserProgrammingModels.aspx"/>
			</slide>
		</part>
		<part id="ajax-practicalities">
			<title>Ajax Practicalities</title>
			<slide>
				<title>Same-Origin Policy</title>
				<ul>
					<li>Browsers combine content from various sources</li>
					<ul>
						<li>HTML loaded from one site</li>
						<li>images/CSS/scripting may come from other sites</li>
						<li>resources are identified by URIs which may point anywhere</li>
					</ul>
					<li>Content may have data integrity and privacy implications</li>
					<ul>
						<li>stealing cookies effectively means stealing an authenticated session</li>
						<li>access to content should be isolated across sites</li>
					</ul>
					<li><em href="http://en.wikipedia.org/wiki/Same_origin_policy">Same-Origin Policies</em> isolate content by domain name</li>
					<ul>
						<li>not perfect and can be circumvented with certain types of attacks</li>
						<li>the first policy implemented on the Web and the only one you can trust</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title><code>XMLHttpRequest</code> Implementations</title>
				<ul>
					<li>Different browsers support different implementations</li>
					<ul>
						<li>IE started supporting it as a browser-specific functionality</li>
						<li>standardization took a while to complete the official API</li>
					</ul>
					<li>Developers have to deal with the different APIs in browsers</li>
					<ul>
						<li>code has to deal with different APIs</li>
						<li>code has to be changed when new browsers show new behavior</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="js-frameworks">
			<title>JavaScript Frameworks</title>
			<slide>
				<title>Abstraction and Reality</title>
				<ul>
					<li>Browsers are not entirely standards-compliant</li>
					<ul>
						<li><a href="http://www.acidtests.org/">Acid Tests</a> are a way how to test browser compliance</li>
						<li>compliance depends on what you test for (versions of the standards)</li>
					</ul>
					<li>Running <a href="http://acid3.acidtests.org/">Acid3</a> for current browsers is disappointing</li>
					<ul>
						<li>Chrome and Safari are equal (because they both use <a href="http://webkit.org/">WebKit</a>)</li>
						<li>Firefox and Opera are not that bad (but not perfect)</li>
						<li>IE8 is a disaster</li>
					</ul>
					<li>In some cases, implementations have to make guesses</li>
					<ul>
						<li>complex combinations of HTML, CSS, and JavaScript interactions</li>
					</ul>
					<li>JavaScript frameworks have two major functions</li>
					<ol>
						<li>hiding the fact that browsers need a lot of special case handling</li>
						<li>providing support for common Web design patterns</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title><code>XMLHttpRequest</code> in jQuery (Setup)</title>
				<listing src="jquery.js" line="4772-4807"/>
			</slide>
			<slide>
				<title><code>XMLHttpRequest</code> in jQuery (Interface)</title>
				<listing src="jquery.js" line="4726-4749"/>
			</slide>
			<slide>
				<title><code>XMLHttpRequest</code> in jQuery (Core)</title>
				<listing src="jquery.js" line="4813-4868"/>
			</slide>
			<slide>
				<title>Web Design Patterns</title>
				<ul>
					<li>Many Web pages use similar ideas/visualizations</li>
					<li>Factoring them into <em>design patterns</em> enables tool support</li>
					<li>Providing access to a tree-structured set of resources</li>
					<ul>
						<li><a href="http://developer.yahoo.com/yui/examples/treeview/folder_style.html">folder views</a> are a common design pattern</li>
					</ul>
					<li>Displaying image captions based on mouse events</li>
					<ul>
						<li><a href="http://homegel.co.za/imagecaption/">dynamic image captions</a> help combining images and their captions</li>
					</ul>
					<li>Tabs are well-known from desktop applications and popular in Web design</li>
					<ul>
						<li><a href="http://extjs.com/deploy/dev/examples/tabs/tabs.html">Ajax Tabs</a> can even load content dynamically</li>
					</ul>
					<li>Image-heavy Web sites might need image viewing support</li>
					<ul>
						<li><a href="http://demos.dojotoolkit.org/demos/cropper/">image zooming</a> can make it more convenient to zoom into images</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Popular Frameworks</title>
				<ul>
					<li>Different needs produce different frameworks</li>
					<ul>
						<li><a href="http://jquery.com/">jQuery</a></li>
						<li><a href="http://www.dojotoolkit.org/">Dojo</a></li>
						<li><a href="http://developer.yahoo.com/yui/">Yahoo! YUI Library</a></li>
					</ul>
					<li>There is no such thing as the <q>best JavaScript framework</q></li>
					<ul>
						<li>for any given project, decide on the support you need</li>
						<li>evaluate frameworks for the support they provide</li>
						<li>evaluate for <em>functional requirements</em> (<q>is there a collapse/expand folder view?</q>)</li>
						<li>evaluate for <em>non-functional requirements</em> (<q>is the framework openly licensed</q>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Important Framework Questions</title>
				<ul>
					<li>How big is it?</li>
					<li>How is it licensed?</li>
					<li>How is it maintained?</li>
					<li>How well does it support graceful degradation?</li>
					<li>How well does it mix with other JavaScript code?</li>
				</ul>
			</slide>
		</part>
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>Scripting has become as essential part of Web-based applications</li>
				<li><em>DHTML</em> is local scripting, <em>Ajax</em> is scripting + server access</li>
				<ul>
					<li>Ajax implements a lightweight client/server model</li>
					<li>Ajax can range from helper functions to complete client-side applications</li>
					<li>Creating better interfaces for Ajax applications is a research topic</li>
				</ul>
				<li>Deciding between client-side and server-side is hard</li>
				<li>JavaScript frameworks help developing script-based applications</li>
				<li>Graceful degradation becomes more important on the mobile Web</li>
			</ul>
		</slide>
	</presentation>
	<presentation id="xss">
		<title short="XSS">Cross Site Scripting (XSS)</title>
		<date>2010-02-19</date>
		<toc class="reading"><a href="http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/iPhoneWebAppHIG" title="iPhone Human Interface Guidelines for Web Applications">iPhone Web App HIG</a></toc>
		<toc class="resources"><a href="http://www.ibm.com/developerworks/library/wa-aj-jsonp1/" title="Cross-domain communications with JSONP, Part 1: Combine JSONP and jQuery to quickly build powerful mashups">JSONP&#160;&amp;&#160;jQuery</a>&#160;· <a href="http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass" title="Apache Documentation: ProxyPass Directive">ProxyPass</a></toc>
		<toc class="abstract">Many mobile applications use data from a variety of sources, the most popular example being map-based applications with often combine map data from one site with placemarks and other map overlays from a different source. Depending on the implementation, this design might be limited by the <em>Same-Origin Policy</em> implemented by clients, which originated in an attempt to reduce the risks of <em>Cross-Site Scripting (XSS)</em>. In this practical lecture, we look at some of the workarounds that are possible, specifically at <em>JSON with Padding (JSONP)</em>, which is a client-based approach, and at <em>reverse proxying</em>, which is a server-based approach.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>XSS Risk and Mitigation</title>
			<slide>
				<title>XSS Risk: Cookie Theft</title>
				<listing src="xss.html"/>
				<listing src="include.html"/>
			</slide>
			<slide id="ajax-same-origin">
				<title>Same-Origin Policy</title>
				<ul>
					<li>Browsers combine content from various sources</li>
					<ul>
						<li>HTML loaded from one site</li>
						<li>images/CSS/scripting may come from other sites</li>
						<li>resources are identified by URIs which may point anywhere</li>
					</ul>
					<li>Content may have data integrity and privacy implications</li>
					<ul>
						<li>stealing cookies effectively means stealing an authenticated session</li>
						<li>access to content should be isolated across sites</li>
					</ul>
					<li><em href="http://en.wikipedia.org/wiki/Same_origin_policy">Same-Origin Policies</em> isolate content by domain name</li>
					<ul>
						<li>not perfect and can be circumvented with certain types of attacks</li>
						<li>the first policy implemented on the Web and the only one you can trust</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Mobile Applications and XSS</title>
				<ul>
					<li>Mobile applications often use different services</li>
					<ul>
						<li>the limitations of browsers can be inconvenient</li>
						<li>cooperation with <q>well-behaving</q> 3rd-parties can be essential</li>
					</ul>
					<li>Accepting <q>data</q> from 3rd parties can be risky</li>
					<ul>
						<li>many <q>data</q> formats have the capability to embed code</li>
						<li>any data format that can embed code should be properly sanitized</li>
						<li>if data formats can load more data (and code), things become very complicated</li>
					</ul>
					<li>Proper sanitization should be done by all applications</li>
					<ul>
						<li>many applications do not sanitize and there should be a fallback</li>
						<li>if applications willingly allow XSS they should be risk-aware</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Allowing XSS</title>
				<ul>
					<li>Server-side methods channel everything through one domain</li>
					<ol>
						<li>write a program that accepts and forwards requests (custom proxy)</li>
						<li>use an HTTP proxy and configure it as a <q>reverse proxy</q></li>
					</ol>
					<li>Client-side methods engineer around the browser security model</li>
					<ul>
						<li>same-origin policies only apply to some resource classes</li>
						<li>cleverly reusing unrestricted access circumvents same-origin policies</li>
					</ul>
					<li>Requesting scripts vs. requesting data from within scripts</li>
					<ul>
						<li>scripts can be requested from any origin</li>
						<li>scripts can request data only from the same origin they're from</li>
						<li>but scripts can request other scripts to be loaded</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Client-Side Solution</title>
			<slide>
				<title><code>XMLHttpRequest</code> Restrictions</title>
				<ul>
					<li><code>XMLHttpRequest</code> in its original design implements the same-origin policy</li>
					<ul>
						<li><code href="http://www.w3.org/TR/XMLHttpRequest">XMLHttpRequest</code> implements the same-origin policy</li>
						<li><code href="http://www.w3.org/TR/XMLHttpRequest2">XMLHttpRequest2</code> is less limited but not yet widely deployed</li>
					</ul>
					<li>HTML has a number of elements without request policies</li>
					<ul>
						<li><htmel>img</htmel> requests images from any domain</li>
						<li><htmel>iframe</htmel> requests HTML from any domain</li>
						<li>HTML has a <a href="http://dret.typepad.com/dretblog/2009/10/links-in-html.html">large number of linking elements</a></li>
						<li><htmel>script</htmel> is a link to a script that is loaded and executed</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>JSON is JavaScript</title>
				<ul>
					<li><code>XMLHttpRequest</code> implements the idea of script-based data access</li>
					<ul>
						<li>access is limited by the same-origin policy</li>
					</ul>
					<li><htmel>script</htmel> is not limited by any security policy</li>
					<li>Scripts adding new script elements is legal and unrestricted</li>
					<ul>
						<li>this does not add new risks to the risky practice of loading 3rd-party scripts</li>
						<li>there is quite a bit of risk to the practice of loading 3rd-party scripts</li>
					</ul>
				</ul>
			</slide>
			<slide id="jsonp">
				<title>JSON with padding (JSONP)</title>
				<ul>
					<li>Serve JSON as a script instead of just data</li>
					<ul>
						<li>JSON data is just a data structure</li>
						<pre>{ "JSON" : "Hello World!"}</pre>
						<li>JSONP data is a function call and thus can be executed</li>
						<pre>jsonp({ "JSON" : "Hello World!"})</pre>
					</ul>
					<li>JSONP-aware services must serve data with the <q>padding</q></li>
					<ul>
						<li>many JSONP services support setting the function name in the URI</li>
						<pre href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=json&amp;jsoncallback=flickrfeed">http://api.flickr.com/…&amp;format=json&amp;jsoncallback=flickrfeed</pre>
					</ul>
					<li>JSONP clients must implement the <q>JSONP function call</q></li>
					<ul>
						<li>the control flow is the same as for Ajax</li>
						<li>the handler function is called as soon as the JSONP script loads</li>
					</ul>
					<li>jQuery handles JSONP internally</li>
				</ul>
			</slide>
			<slide>
				<title>JSONP Example</title>
				<listing src="mobapp2010.jsonp" line="1-22" href="http://api.flickr.com/services/feeds/geo/?g=1313291@N20&amp;lang=en-us&amp;format=json"/>
			</slide>
			<slide>
				<title>JSONP Handling in jQuery</title>
				<listing src="jquery.js" line="4825-4868"/>
			</slide>
		</part>
		<part>
			<title>Server-Side Solution</title>
			<slide>
				<title>HTTP Server Configuration</title>
				<ul>
					<li><code>XMLHttpRequest</code> requests are subject to the same-origin policy</li>
					<ul>
						<li>accept requests for a 3rd-party URI at some same origin URI</li>
						<li><q>forward</q> the request to the 3rd-party URI</li>
					</ul>
					<li>Proxies are used for re-engineering HTTP traffic</li>
					<ul>
						<li><link href="forward-proxy">forward proxies</link> are configured and used by the client</li>
						<li><link href="reverse-proxy">reverse proxies</link> are configured and used by the server</li>
					</ul>
					<li>The solution we need is a reverse proxy</li>
					<ul>
						<li>not visible for the client (looks like a same-origin request)</li>
						<li>passed through to the 3rd party server (additional HTTP hop)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Requirements</title>
				<ul>
					<li>Apache needs to support proxying and rewriting URIs</li>
					<pre>LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule rewrite_module modules/mod_rewrite.so</pre>
					<li>Proxying support allows the server to <em>make HTTP requests</em></li>
					<li>Rewriting allows the server to map <q>incoming</q> URIs to <q>outgoing</q> requests</li>
				</ul>
			</slide>
			<slide>
				<title>Mapping Remote Resources</title>
				<pre>
RewriteEngine On
ProxyRequests Off
&lt;Proxy *>
	Order deny,allow
	Allow from all
&lt;/Proxy>
RewriteRule ^/staticmap(.*) http://maps.google.com/maps/api/staticmap$1 [P]</pre>
			</slide>
		</part>
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>Combining data can take a bit of engineering</li>
				<li>Creativity in re-engineering can help solving problems</li>
				<li>Creativity in re-engineering can introduce vulnerabilities</li>
				<li>Mobile applications are particularly vulnerable</li>
				<ul>
					<li>users trust and handle their mobile devices differently</li>
					<li>badly engineered applications can cause a lot of damage</li>
				</ul>
				<li>Do not trust anybody you don't have to</li>
			</ul>
		</slide>
	</presentation>
	<presentation id="ui" external="ui-design.pdf">
		<title short="UI Design">Designing Mobile User Interfaces</title>
		<date>2010-02-22</date>
		<toc class="author">Jeffrey Nichols</toc>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/mobile_web_development" title="Mobile Design and Development; Chapter 8: Mobile Design">Mobile Design</a></toc>
		<toc class="resources"><a href="https://courses.ischool.berkeley.edu/i213/s10/readings/ballard-ch1-introduction.pdf" title='Barbara Ballard, "Designing the Mobile User Experience", Wiley, 2007; Chapter 1: Introduction - Mobility is Different'>Mobility is Different</a>&#160;· <a href="https://courses.ischool.berkeley.edu/i213/s10/readings/ballard-ch9-research-and-design-process.pdf" title='Barbara Ballard, "Designing the Mobile User Experience", Wiley, 2007; Chapter 9: Research and Design Process'>Research and Design Process</a></toc>
		<toc class="abstract">In this lecture, I'll describe both the general process for designing user interfaces and variety of guidelines for designing mobile user interfaces. The mobile guidelines are based on a variety of studies conducted at IBM, my own personal experience, and Barbara Ballard's book <q>Designing the Mobile User Experience</q>.</toc>
	</presentation>
	<presentation id="ux" external="ui-evaluation.pdf">
		<title short="UI Evaluation">Evaluating and Iterating on Mobile User Interfaces</title>
		<date>2010-02-24</date>
		<toc class="author">Jeffrey Nichols</toc>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/mobile_web_apps_versus_native_applicat" title="Mobile Design and Development; Chapter 9: Mobile Web Apps Versus Native Applications">Mobile Web vs. Native</a></toc>
		<toc class="resources"><a href="doi.ieeecomputersociety.org/10.110910.1109/MPRV.2003.1203750" title='Sunny Consolvo and Miriam Walker, "Using the Experience Sampling Method to Evaluate Ubicomp Applications", IEEE Pervasive Computing 2(2), April-June 2003, pp. 24-31'>Using the Experience Sampling Method to Evaluate Ubicomp Applications</a></toc>
		<toc class="abstract">In this lecture, I'll describe a variety of methods for evaluating mobile user interfaces. These vary from traditional lab-based user interface evaluation methods, including heuristic analysis and think-aloud studies, to field-based methods that are better suited to mobile interfaces, such as diary studies, the experience sampling method, and logging studies.</toc>
	</presentation>
	<presentation id="mobileweb">
		<title short="Mobile Web">Mobile Web vs. Web</title>
		<date>2010-02-26</date>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/types_of_mobile_applications" title="Mobile Design and Development; Chapter 6: Types of Mobile Applications">Types of Mobile Apps</a></toc>
		<toc class="resources"><a href="http://blog.taptu.com/2010/02/03/touchfriendlywebreport/" title="Introducing the State of The Mobile Touch Web Report">Touch Web</a>&#160;· <a href="http://en.wikipedia.org/wiki/Acid3">Acid3 Test</a>&#160;· <a href="http://www.css3.info/selectors-test/">CSS3 Selectors Test</a>&#160;· <a href="http://www.w3.org/2005/MWI/Tests/blog/2010/02/09/wctmbv2">Mobile Browser Test</a></toc>
		<toc class="abstract"><em>Web-based mobile applications</em> inherit important properties and constraints both because of their dependency on the <em>Web</em>, and because of their focus on <em>mobile scenarios</em>. In the previous two lectures, we have looked at the differences caused by typical mobile device usage, which often translate into different designs, and might even make Web-based solutions less than optimal in some situations. From the technical perspective, an important question is how easy it is to design and build Web-based applications for mobile devices, and in this lecture we look at the most important component in that picture, the <em>mobile browser</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Mobile Browsers and Browsers</title>
			<slide>
				<title>Mobile's Share of Web Consumption</title>
				<img src="mobile-web-share.png" style="height : 65% ; margin : 4% ; " href="http://www.quantcast.com/docs/display/info/Mobile+Report"/>
			</slide>
			<slide>
				<title>Smartphone Sales Q2 2009</title>
				<img src="smartphone-os-q2-2009.png" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Smartphone"/>
			</slide>
			<slide>
				<title>Web Requests by Smartphone OS</title>
				<img src="smartphone-os-share.png" style="height : 65% ; margin : 4% ; " href="http://metrics.admob.com/?mkt_tok=3RkMMJWWfF9wsRovu6vfLqzsmxzEJ8n77ukuX7Hr08Yy0EZ5VunJEUWy0IMD"/>
			</slide>
			<slide>
				<title>Browser Wars Revisited</title>
				<ul>
					<li>Two major developments are referred to as <a href="http://en.wikipedia.org/wiki/Browser_wars">Browsers Wars</a></li>
					<ul>
						<li>Netscape vs. IE in the late 1990s</li>
						<li>IE vs. others (Mozilla, Safari, Opera, ) since 2003</li>
					</ul>
					<li>Economic battles fought with policies and technological weaponry</li>
					<ul>
						<li>deploy default browsers on major platforms</li>
						<li>make it hard for users to change their default browser</li>
						<li>make browsers and other Internet software behave like malware</li>
						<li>introduce features and deploy tools that depend on these features</li>
					</ul>
					<li>Browser wars consume a lot of energy</li>
					<ul>
						<li>browser developers concentrate on features and not on quality</li>
						<li>content developers have to negotiate the battlefield</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Browser War I</title>
				<img src="browser-war-one.png" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Browser_wars#The_first_browser_war"/>
			</slide>
			<slide>
				<title>Browser War II</title>
				<table>
					<tr>
						<td>
							<img src="browser-war-two.png" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/Browser_wars#The_second_browser_war"/>
						</td>
						<td>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:red solid 1px;; background-color:red; color:red">&#160;&#160;&#160;&#160;</span>&#160;Firefox</span>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:green solid 1px;; background-color:green; color:green">&#160;&#160;&#160;&#160;</span>&#160;Safari</span>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:teal solid 1px;; background-color:teal; color:teal">&#160;&#160;&#160;&#160;</span>&#160;Opera</span>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:blue solid 1px;; background-color:blue; color:blue">&#160;&#160;&#160;&#160;</span>&#160;Netscape</span>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:purple solid 1px;; background-color:purple; color:purple">&#160;&#160;&#160;&#160;</span>&#160;Mozilla</span>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:black solid 1px;; background-color:black; color:black">&#160;&#160;&#160;&#160;</span>&#160;Chrome</span>
							<span style="margin:0px; padding-bottom:1px; font-size:90%; display:block;"><span style="border:Orange solid 1px;; background-color:Orange; color:Orange">&#160;&#160;&#160;&#160;</span>&#160;Other</span>						
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>Browser War III</title>
				<ul>
					<li>Mobile browsers are platforms for mobile applications</li>
					<ul>
						<li>competition with native applications requires advanced browser capabilities</li>
						<li>mobile devices vary widely in their features and configurations</li>
						<li>defining <q>the standard <link href="platforms">mobile platform</link></q> is more challenging than for computers</li>
					</ul>
					<li>Many mobile platforms are designed like old <q>fat clients</q></li>
					<ul>
						<li>have a basic browser for simple and low-fidelity tasks</li>
						<li>require installed native applications for more advanced tasks</li>
					</ul>
					<li>Computers moved away from <q>fat clients</q> a while ago</li>
					<ul>
						<li><q>thin clients</q> are more cost-effective (less local maintenance)</li>
						<li>managing data and applications in the <q>cloud</q> adds flexibility</li>
						<li>robust browser support allows advanced applications (<em href="http://en.wikipedia.org/wiki/Web_2.0">Web 2.0</em>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Application Stores</title>
				<ul>
					<li><q>Application Stores</q> remove some of the native application problems</li>
					<ul>
						<li>unified billing platform (<q>eBay for applications</q>)</li>
						<li>one-stop shop (catalog and search functions)</li>
						<li>quality control (stability and security issues)</li>
						<li>ease of installation (one-click installation procedure)</li>
					</ul>
					<li><q>Application Stores</q> introduce typical monopoly problems</li>
					<ul>
						<li>opaque procedures for acceptance to the store</li>
						<li>no competition and thus skewed economies</li>
						<li>highly centralized market instead of decentralized ecosystem</li>
					</ul>
					<li>The lifetime of today's application stores is probably limited</li>
				</ul>
			</slide>
		</part>
		<part>
			<title>Browser Evaluation</title>
			<slide>
				<title>Mobile Browser Evolution</title>
				<ul>
					<li><em>Mobile Safari</em> was the first desktop-quality mobile browser</li>
					<ul>
						<li>almost all features of the desktop version of Safari</li>
						<li>unique properties and problems because of the multi-touch interface</li>
					</ul>
					<li><q>Touch Web</q> is a new term for explicitly <q>touch-friendly</q> Web pages</li>
					<ul>
						<li>current focus is on being friendly to small-screen devices</li>
						<li>iPad and other tablets may create a new category of large-screen touch browsers</li>
					</ul>
					<li>Identifying the target group for an application is not easy</li>
					<ul>
						<li>native applications always will only work on one platform</li>
						<li>Web-based applications can work across platforms</li>
						<li>projections for application lifetime and update frequency are essential</li>
					</ul>
				</ul>
			</slide>
			<slide id="acid2">
				<title>Acid2</title>
				<listing src="acid2.html" line="19-34" href="http://acid2.acidtests.org/"/>
			</slide>
			<slide id="css3-selectors-test">
				<title>CSS3 Selectors Test</title>
				<ul>
					<li>CSS3 adds <a href="http://www.w3.org/TR/css3-selectors/">more selectors to CSS</a></li>
					<ul>
						<li>better capabilities to apply formatting to specific elements</li>
					</ul>
					<li>Reduces the need for non-declarative mechanisms</li>
					<ul>
						<li>less need to use a lot of identifying <html>class</html> attributes</li>
						<li>less need for scripting to identify certain element <q>classes</q></li>
					</ul>
					<li><a href="http://tools.css3.info/selectors-test/test.html">Testing CSS3 selectors</a> identifies CSS-savvy browsers</li>
				</ul>
				<pre href="http://www.w3.org/TR/css3-selectors/#nth-child-pseudo">tr:nth-child(2n+1) /* represents every odd row of an HTML table */
tr:nth-child(odd)  /* same */
tr:nth-child(2n+0) /* represents every even row of an HTML table */
tr:nth-child(even) /* same */
</pre>
			</slide>
			<slide id="acid3">
				<title>Acid3</title>
				<ul>
					<li><a href="http://en.wikipedia.org/wiki/Acid2">Acid2</a> tested only for CSS2 implementation</li>
					<ul>
						<li>testing CSS selectors to always select the correct elements</li>
						<li>testing CSS properties to produce the correct layout</li>
					</ul>
					<li>Acid3 adds a number of <q>Web 2.0 technologies</q></li>
					<ul>
						<li>JavaScript and DOM2 for basic scripting compatibility</li>
						<li>SVG, XML, and <code>data</code> URIs for additional functionality</li>
					</ul>
					<li>Six major groups of tests (called <q>buckets</q>)</li>
					<ol>
						<li>DOM Traversal, DOM Range, HTTP</li>
						<li>DOM2 Core and DOM2 Events</li>
						<li>DOM2 Views, DOM2 Style, CSS 3 selectors and Media Queries</li>
						<li>Behavior of HTML  tables and forms when manipulated by script and DOM2 HTML</li>
						<li>Tests from the Acid3 Competition</li>
						<li>ECMAScript</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Acid3 Result</title>
				<img src="acid3-ff36.png" style="height : 65% ; margin : 4% ; " href="http://acid3.acidtests.org/" title="Acid3 for Firefox 3.6"/>
			</slide>
			<slide>
				<title>W3C Mobile Browser Test</title>
				<ul>
					<li>Very specific choice of tested technologies</li>
					<ul>
						<li><code>XMLHttpRequest</code></li>
						<li><htmel>canvas</htmel></li>
						<li><html>contenteditable</html></li>
						<li>geolocation API</li>
						<li><htmel>input type="date"</htmel></li>
						<li>AppCache (offline launching for Web-based applications)</li>
						<li><htmel>video</htmel></li>
						<li><htmel>audio</htmel></li>
						<li>Web Workers (<q>threads</q> for scripting)</li>
						<li>local storage (persistent local key/value storage)</li>
						<li>session storage (temporary local key/value storage)</li>
						<li><html>@font-face</html></li>
					</ul>
					<li><a href="http://www.w3.org/2010/01/wctmb2/">Testing browsers</a> is easy but might miss some details</li>
					<ul>
						<li><htmel>video</htmel>/<htmel>audio</htmel> critically depend on the supported codecs</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Developing Mobile Web Applications</title>
			<slide>
				<title>Targeting One Platform</title>
				<ul>
					<li>The Web is becoming increasingly segmented</li>
					<ul>
						<li>vast majority of accesses are from regular computers (PC/laptop)</li>
						<li>increasing share of accesses are from smartphones (mobile Web)</li>
						<li><q>other platforms</q> such as tablets, e-books, cars, consoles, …</li>
					</ul>
					<li>Use the correct statistics based on your audience</li>
					<ul>
						<li>platforms vary greatly across countries</li>
						<li>platform usage can change fairly quickly over time</li>
					</ul>
					<li>Targeting a single platform is high risk and high profit</li>
					<ul>
						<li>cheaper development than native applications</li>
						<li>UX not as polished as with native applications</li>
						<li>same platform limitations as native applications</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Least Common Denominator</title>
				<ul>
					<li>The <q>least common denominator</q> is really low</li>
					<ul>
						<li>state-of-the-art mobile browsers are limited to smartphones</li>
						<li>most regular phones have very minimal WAP-inspired browsers</li>
						<li>basic HTML, no CSS, no scripting</li>
					</ul>
					<li>Trade-off between audience and sophistication</li>
					<ul>
						<li>good as a utilitarian approach if people have to use a service</li>
						<li>risky as an approach where people have to become engaged</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Class-Based Development</title>
				<ul>
					<li>Good theory but hard to implement in practice</li>
					<ul>
						<li>what are the most useful <q>classes</q> to identify?</li>
						<li>how to reuse as much content/code across classes?</li>
						<li>how to make sure that class cost match class coverage?</li>
					</ul>
					<li>Nowadays often implemented in a two-class approach</li>
					<ul>
						<li><q>regular site</q> assuming a laptop/desktop computer and environment</li>
						<li><q>mobile site</q> either very basic (WAP) or touch-specific (iPhone)</li>
					</ul>
					<li>Publishing/authoring frameworks might become more sophisticated</li>
					<ul>
						<li>generating different versions of sites (based on target audiences)</li>
						<li><a href="http://www.w3.org/TR/css3-mediaqueries/">CSS Media Queries</a> allow better client-side adaptation</li>
					</ul>
				</ul>
				<pre href="http://www.w3.org/TR/css3-mediaqueries/#orientation">@media all and (orientation:portrait) { … }
@media all and (orientation:landscape) { … }</pre>
				<pre href="http://www.w3.org/TR/css3-mediaqueries/#monochrome">&lt;link rel="stylesheet" media="print and (color)" href="http://…" />
&lt;link rel="stylesheet" media="print and (monochrome)" href="http://…" /></pre>
			</slide>
			<slide>
				<title>Translation/Adaptation</title>
				<ul>
					<li>Fully automated approaches are research topics</li>
					<ul>
						<li>usual problem of perfect separation of content and layout</li>
						<li>many research projects are based on the idea of pure content</li>
						<li>many real-world projects use a mix of content and layout</li>
					</ul>
					<li>Database-driven solutions typically are good candidates</li>
					<ul>
						<li>the content almost by definition has no inherent layout</li>
						<li>designing translation/adaptation has a good starting point</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="platforms">
		<title short="Platforms">Mobile Platforms</title>
		<date>2010-03-01</date>
		<toc class="resources"><a href="http://dret.typepad.com/dretblog/html5-api-overview.html" title="HTML5 API Overview">HTML5 APIs</a>&#160;· <a href="http://www.infoq.com/presentations/PhoneGap-Mobile-Applications-with-HTML-CSS-JavaScript" title="PhoneGap: Mobile Applications with HTML, CSS and JavaScript (Presented by Brian LeRoux on Dec 16, 2009)">PhoneGap</a></toc>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Add Map-based Contents to a Mobile Application">A4: Maps</a> (assigned: 3/1; due: 3/8)</toc>
		<toc class="abstract">This lecture takes a closer view of the spectrum between native and Web-based mobile apps. Specifically, we look at the gap, how that gap might be closed by the activities referred to as <em>HTML5</em>, and what still remains as open issues even with HTML5. We also look at the hybrid approaches such as <em>PhoneGap</em>, and at the more desktop-inspired approaches of <em>Flash Light</em> and <em>JavaFX</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Delivering Mobile Web Applications</title>
			<slide>
				<title>URIs for Mobile Resources</title>
				<img src="qr.png" style="float : right ; margin : 0 1em 2em 2em ; width : 20% " href="http://chart.apis.google.com/chart?cht=qr&amp;chs=500x500&amp;chl=http://dret.net/lectures/mobapp-spring10/" title="QR Code for http://dret.net/lectures/mobapp-spring10/"/>
				<ul>
					<li>URIs identify resources for interactions</li>
					<li>Perfect URIs are independent of the actual representation</li>
					<ul>
						<li>more an ideal than something that is often done in practice</li>
					</ul>
					<li>URIs should be the <em>entry point</em> to interactions</li>
					<ul>
						<li>identifiers that can be published, shared, reused, …</li>
						<li>there should only be one entry point</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title><q>One Web</q> URIs</title>
				<ul>
					<li>Ideally, all interactions go through the same set of URIs</li>
					<li>In practice, Web sites can be structured/designed very differently</li>
					<ul>
						<li>mobile applications are based on different use cases and usages</li>
						<li>mobile sites may have a different URI structure from the regular site</li>
					</ul>
					<li>Different approaches for handling <q>One Web URIs</q></li>
					<ul>
						<li>perfect: serve content that may be specific to the request</li>
						<li>good: redirect to content that is specific to the request</li>
						<li>sometimes good: allow users to <q>switch</q> between different representations</li>
					</ul>
					<li>Different representations often are developed by different teams</li>
					<ul>
						<li>not necessarily a one-to-one correspondence between all resource</li>
						<li>try to provide mappings between the most important resource URIs</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title><q>Mobile Web</q> URIs</title>
				<ul>
					<li>Most mobile sites use specific URIs for mobile content</li>
					<ul>
						<li>different TLD: <code>http://berkeley.mobi/</code></li>
						<li>different domain: <code>http://m.berkeley.edu/</code></li>
						<li>different path: <code>http://berkeley.edu/mobile</code></li>
					</ul>
					<li><code>.mobi</code> has not seen much adoption</li>
					<ul>
						<li>there is no reason why mobile content should have one specific TLD</li>
					</ul>
					<li>Different subdomains make it easy to set up separate servers</li>
					<ul>
						<li>convenient for entirely different mobile applications</li>
						<li>high risk of fragmentation and partial reuse becomes brittle</li>
					</ul>
					<li>Different paths are creating as little separation as possible</li>
					<ul>
						<li>all content is available through the same server</li>
						<li>setting up and maintaining redirects can be handled more easily</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Native Runtime Platforms</title>
			<slide>
				<title>Mobile Platform Overview</title>
				<img src="mobile-platform.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>The Legacy of J2ME</title>
				<ul>
					<li>J2ME was a disaster in usability and stability</li>
					<li>Instead of selling implementations, it was a licensed spec</li>
					<ul>
						<li>there were no conformance requirements and no conformance testing</li>
						<li>anything that was labeled as <q>J2ME</q> could be shipped</li>
					</ul>
					<li>Installation procedures were/are not user-friendly</li>
					<ul>
						<li>phone-specific ways of how to download/install applications</li>
						<li>often no easy way to find and manage installed applications</li>
					</ul>
					<li>Developing J2ME applications became surprisingly device-specific</li>
					<ul>
						<li>writing code to address/circumvent properties of devices</li>
						<li>far from Java's original <q>Write Once, Run Anywhere</q> vision</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Tightly Controlled Platforms</title>
				<ul>
					<li>iPhone development works well because there is only one device</li>
					<ul>
						<li>3GS supports video and has a compass but those are all differences</li>
					</ul>
					<li>iPad development makes development considerably harder</li>
					<ul>
						<li>much larger differences in device capabilities</li>
						<li>maybe a completely different UX/UI approach is required</li>
					</ul>
					<li>Tightly controlled platforms allow better tool chains</li>
					<ul>
						<li>SDK and other tools are under control by one vendor</li>
					</ul>
					<li>The long story of <em href="http://daringfireball.net/2010/01/apple_adobe_flash">Flash on the iPhone</em></li>
					<ul>
						<li>Apple controls the complete code base running iPhone applications</li>
						<li>Flash would introduce code controlled by a different vendor</li>
						<li>stability/performance issue cannot be addressed by Apple</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Open and/or Licensed Platforms</title>
				<ul>
					<li>More open models mean platforms are reused for various devices</li>
					<ul>
						<li>Android is open source and reaches beyond smartphones (<em href="http://en.wikipedia.org/wiki/Barnes_&amp;_Noble_Nook">nook</em>, netbooks)</li>
						<li>Windows Mobile is licensed to a variety of device makers</li>
					</ul>
					<li>Device diversity can become a problem</li>
					<ul>
						<li>diversity is good but also makes it harder to rely on device capabilities</li>
						<li>until today, all Windows Mobile devices are required to have IR ports</li>
					</ul>
					<li>Android development is a different challenge from the iPhone</li>
					<ul>
						<li>development for only one device?</li>
						<li>if for multiple devices, what is the target class of devices?</li>
						<li>development across classes faces the iPhone/iPad challenge</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Cross-Platform Development</title>
				<table width="80%" style="margin : 3%">
					<thead>
						<tr>
							<th>Platform</th>
							<th>Language</th>
							<th>Sophistication</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>iPhone</td>
							<td>Objective C</td>
							<td>complicated &amp; polished</td>
						</tr>
						<tr>
							<td>Android</td>
							<td>Java</td>
							<td>Eclipse</td>
						</tr>
						<tr>
							<td>Blackberry</td>
							<td>Java</td>
							<td>not great</td>
						</tr>
						<tr>
							<td>Windows Mobile</td>
							<td>.NET and/or C#</td>
							<td>complex</td>
						</tr>
						<tr>
							<td>Nokia (Maemo/MeeGo)</td>
							<td>C++, Java, Flash Light, Web techs</td>
							<td>not focused</td>
						</tr>
						<tr>
							<td>Palm (WebOS)</td>
							<td>Web techs</td>
							<td>?</td>
						</tr>
					</tbody>
				</table>
			</slide>
		</part>
		<part>
			<title>Web-Based Runtime Platforms</title>
			<slide>
				<title>Web-Based Mobile Platform</title>
				<img src="mobile-platform-web-based.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>iPhone Platform</title>
				<img src="mobile-platform-iphone.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>Web as a Platform</title>
				<ul>
					<li>Code is delivered on demand using Web standards</li>
					<ul>
						<li>HTML is the interface structure language (the <q>windowing metaphor</q>)</li>
						<li>CSS is the layout language (layout controls for the <q>windowing metaphor</q>)</li>
						<li>JavaScript is the programming language (runtime control of HTML/CSS)</li>
						<li>HTTP is the communication method (JavaScript access to the Internet)</li>
					</ul>
					<li>Web technologies are migrating into the OS</li>
					<ul>
						<li>a long time ago, Internet technologies were doing the same thing</li>
						<li>HTTP support by the OS still is the exception and not the rule</li>
						<li>more complete packages (rendering &amp; scripting) are available (WebKit)</li>
						<li><em>WebOS</em> treats Web technologies <em>as the native API</em></li>
					</ul>
					<li><em>ChromeOS</em> is using the browser as a platform</li>
					<ul>
						<li>browser = WebKit + user controls (a.k.a. <q href="http://en.wikipedia.org/wiki/User_interface_chrome">chrome</q>)</li>
						<li>ChromeOS and WebOS are not all that different (technically)</li>
					</ul>
				</ul>
			</slide>
			<slide id="current-web">
				<title>Current Web Capabilities</title>
				<ul>
					<li>Web technology is rather limited in its device support</li>
					<ul>
						<li>keyboard/mouse perspective is built into numerous technologies</li>
						<li>output is visual and bitmapped (<q href="http://www.w3.org/TR/CSS21/aural.html#aural-media-group">Aural CSS</q> might still happen)</li>
					</ul>
					<li>Many Web pages rely on non-standardized technologies</li>
					<ul>
						<li><em>Flash</em> for rich media (mostly video playback)</li>
						<li><em>Silverlight</em> for <em>Rich Internet Application (RIA)</em> implementations</li>
					</ul>
					<li>Web technology is limited to online scenarios</li>
					<ul>
						<li>Google tried changing this with <em>Google Gears</em> (offline support)</li>
						<li>offline capabilities are now added in various places</li>
						<li>most Web-based apps by their very nature are online-oriented</li>
					</ul>
				</ul>
			</slide>
			<slide id="html5-overview">
				<title>HTML5 Capabilities</title>
				<ul>
					<li>HTML5 is a complicated and evolving set of technologies</li>
					<ul>
						<li>turning HTML4 into something with more predictable browser behavior</li>
						<li>adding some new features along the way</li>
					</ul>
					<li>Some HTML5 features were spun off into standalone specifications</li>
					<ul>
						<li><a href="http://www.w3.org/TR/workers/">Web Workers</a></li>
						<li><a href="http://www.w3.org/TR/webstorage/">Web Storage</a> and <a href="http://www.w3.org/TR/webdatabase/">Web SQL Database</a></li>
						<li><a href="http://www.w3.org/TR/websockets/">Web Sockets API</a></li>
						<li><a href="http://www.w3.org/TR/selectors-api/">Selectors API Level 1</a> and <a href="http://www.w3.org/TR/selectors-api2/">Selectors API Level 2</a></li>
						<li><a href="http://www.w3.org/TR/eventsource/">Server-Sent Events</a></li>
						<li><a href="http://www.w3.org/TR/XMLHttpRequest/">XMLHttpRequest</a> and <a href="http://www.w3.org/TR/XMLHttpRequest2/">XMLHttpRequest Level 2</a></li>
						<li><a href="http://www.w3.org/TR/geolocation-API/">Geolocation API Specification</a></li>
					</ul>
					<li>Not all documents at the W3C have the same support and maturity</li>
					<ul>
						<li><a href="http://www.w3.org/TR/DataCache/">Programmable HTTP Caching and Serving</a></li>
						<li><a href="http://www.w3.org/TR/contacts-api/">Contacts API</a></li>
						<li><a href="http://www.w3.org/TR/IndexedDB/">Indexed Database API</a> (competitor of <em>Web Storage</em>)</li>
						<li><a href="http://www.w3.org/TR/FileAPI/">File API</a></li>
					</ul>
				</ul>
			</slide>
			<slide id="missing-pieces">
				<title>Missing Pieces</title>
				<ul>
					<li>Non-traditional interactions</li>
					<ul>
						<li>(multi-)touch screen for pointing interactions</li>
						<li>accelerometer for measuring device movement</li>
						<li>vibration for giving tactile feedback</li>
					</ul>
					<li>Access to device hardware</li>
					<ul>
						<li>camera, compass, …</li>
					</ul>
					<li>Access to additional information sources</li>
					<ul>
						<li>phone API for phone calls and messaging</li>
						<li>contacts, calendar, social networks, …</li>
					</ul>
					<li>Special graphics capabilities</li>
					<ul>
						<li>essential for advanced rendering (gaming, 3D visualization)</li>
						<li>non-traditional bitmapped displays such as e-ink</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Hybrid Runtime Platforms</title>
			<slide>
				<title>Java Revisited</title>
				<ul>
					<li><q>Write Once, Run Anywhere</q></li>
					<li>Java's appeal of a virtual platform remains strong</li>
					<ul>
						<li>Java's main success was for non-interactive applications</li>
						<li>abstracting the traditional OS functions probably is easier to do</li>
					</ul>
					<li>Taking Java to the Web</li>
					<ul>
						<li>Java Applets never really took off (too heavyweight and ugly)</li>
						<li>Flash was much more lightweight and more Web-friendly</li>
						<li>ActiveX was Microsoft's backdoor into native features</li>
						<li>Silverlight is both for embedded and standalone applications</li>
						<li>AIR is Adobe's <q>standalone Flash</q></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Embedded in the Browser</title>
				<ul>
					<li>Plugin architectures of browsers allow browser extensions</li>
					<ul>
						<li><htmel href="http://www.w3.org/TR/html401/struct/objects.html#h-13.4">applet</htmel> specifically supports Applets only</li>
						<li><htmel href="http://www.w3.org/TR/html401/struct/objects.html#h-13.3">object</htmel> allows any object to be embedded</li>
					</ul>
					<li>Browsers must have the extension installed for content to work</li>
					<ul>
						<li>plugin installation is complicated and security-sensitive</li>
						<li>fallback can be implemented but often is too costly and not supported</li>
					</ul>
					<li>Browser plugins are not subject to the same security policies</li>
					<ul>
						<li>they run as native code (the plugin is installed as an OS-level library)</li>
						<li>vulnerabilities of the plugin turn into vulnerabilities of the browser</li>
					</ul>
					<li>More lightweight approaches may be required for mobile devices</li>
					<ul>
						<li><em>Flash Light</em> is a version of Flash for limited devices</li>
						<li><em href="http://www.sun.com/software/javafx/">JavaFX</em>  and <em href="http://www.sun.com/software/javafx/mobile/">JavaFX Mobile</em> are intended to replace Applets/J2ME</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Browser/Flash Platform</title>
				<img src="mobile-platform-flash.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>Standalone Runtimes</title>
				<ul>
					<li>Removing the limitations of the browser</li>
					<ul>
						<li>essentially recreating Java's <em>virtual machine</em> approach</li>
						<li>often more friendly to Wen technologies (built-in HTML/CSS/Scripting)</li>
					</ul>
					<li>Transitioning outside of a browser breaks the Web flow</li>
					<ul>
						<li>standalone apps mean that there is no <q>back</q> button</li>
						<li>it is harder to integrate these applications with others</li>
					</ul>
					<li>Most examples of standalone applications are <q>black holes</q></li>
					<ul>
						<li>they are not supposed to connect to the fabric of the Web</li>
						<li>overcoming the <q>black hole</q> effect is easier in a browser</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Flash Standalone Platform (AIR)</title>
				<img src="mobile-platform-android-flash.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>Compiled Runtimes</title>
				<ul>
					<li>Application and runtime compiled into a native application</li>
					<ul>
						<li>less dependency on installation status of the client</li>
						<li>only reasonable with a lightweight runtime</li>
					</ul>
					<li><a href="http://phonegap.com/">PhoneGap</a> acts mostly as glue for native functionality</li>
					<ul>
						<li>exposing currently unsupported functionality as JavaScript APIs</li>
						<li>the actual functionality is supported/implemented in the OS</li>
					</ul>
					<li>PhoneGap focuses platforms that are sophisticated enough</li>
					<ul>
						<li>currently supported are iPhone, Android, and Blackberry</li>
						<li>support is planned for Windows Mobile, Nokia, and Palm</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>PhoneGap on the iPhone</title>
				<img src="mobile-platform-phonegap.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
		</part>
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>Navigating the current landscape is complicated</li>
				<li>Devices, platforms, and technologies are evolving quickly</li>
				<li>There is no <q>best solution</q> for mobile applications</li>
				<li>Web-based applications will see better support in the near future</li>
				<li>Mobile will probably follow the path of the Web</li>
			</ul>
		</slide>
	</presentation>
	<presentation id="geolocation">
		<title>Geolocation</title>
		<date>2010-03-03</date>
		<toc class="resources"><a href="http://www.w3.org/TR/geolocation-API/" title="W3C Geolocation API">Geolocation API</a>&#160;· <a href="http://escholarship.org/uc/item/0rp834wf" title='Nick Doty, Deirdre K. Mulligan, and Erik Wilde, "Privacy Issues of the W3C Geolocation API", UC Berkeley School of Information Report 2010-038, February 2010'>Geolocation Privacy</a>&#160;· <a href="http://npdoty.name/location/">Geolocation Demo</a></toc>
		<toc class="abstract"><em>Mobility</em> is (one of) the defining characteristics of mobile devices, and many use cases and scenarios not only depend on mobility (the ability to move), but on location (the knowledge of where something moved to). Determining the location of a mobile device can be done in a variety of ways, and in this lecture we briefly look at various localization technologies (IP address, Wi-Fi, cell phone, GPS). We then look at the <em>W3C Geolocation API</em>, which is currently under development and allows scripting code to request the location of the device it is running on. Finally, we discuss some privacy issues around automated access to location information.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Mobility and Geolocation</title>
			<ul>
				<li>Mobile devices change position and thus position is interesting</li>
				<ul>
					<li>most abstract mobility information: something moved or is moving</li>
					<li>most concrete: coordinates, elevation, speed, heading</li>
				</ul>
				<li>Location information can be obtained in a number of ways</li>
				<ul>
					<li>the mere act of obtaining location information can produce a location trail</li>
					<li>there should be an abstraction layer for location information</li>
					<li>users might want to control how their location is obtained/exposed</li>
				</ul>
				<li>Location is interesting both technically and economically</li>
				<ul>
					<li>location-based services establish spatial context that is useful in many scenarios</li>
					<li>location information is a useful input for recommendations and advertising</li>
					<li>different scenarios need very different spatial resolution</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Desktop Location</title>
			<img src="google-maps-my-location.png" style="height : 65% ; margin : 4% ; " href="http://google-latlong.blogspot.com/2009/07/blue-circle-comes-to-your-desktop.html"/>
		</slide>
		<part>
			<title>Determining Location</title>
			<slide>
				<title>Where Are You?</title>
				<ul>
					<li>Different devices/situations ask for different methods</li>
					<ul>
						<li>available identifications from network technologies</li>
						<li>available signals for location technologies (<link href="gps">GPS</link>)</li>
					</ul>
					<li><link href="ip-positioning"/> has been used for a long time for targeted advertising</li>
					<ul>
						<li>often not good enough for a precise location</li>
						<li>often good enough for broad categorization (country, state, city)</li>
					</ul>
					<li>Location technology should work robustly and reliably</li>
					<ul>
						<li>determine location under a variety of conditions</li>
						<li>determine location as precisely as possible in a given scenario</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Connectivity Matters</title>
				<table>
					<tr>
						<td>
							<p>IP address from local Wi-Fi:</p>
							<listing src="ip-query-ischool.xml" href="http://ipinfodb.com/ip_query.php" title="IP Query Wi-Fi"/>
						</td>
						<td>
							<p>IP address through AT&amp;T 3G:</p>
							<listing src="ip-query-3g.xml" href="http://ipinfodb.com/ip_query.php" title="IP Query 3G"/>
						</td>
					</tr>
				</table>
			</slide>
			<part id="ip-positioning">
				<title>IP Positioning</title>
				<slide id="ip-address">
					<title>Internet Addressing</title>
					<ul>
						<li>Basic Internet connectivity requires IP addresses</li>
						<ul>
							<li>each device connected to the Internet has an IP address</li>
						</ul>
						<li>IP addresses are assigned and used in blocks</li>
						<ul>
							<li><q href="http://en.wikipedia.org/wiki/Classful_network#Introduction_of_address_classes">Class A</q> networks <a href="http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml">are assigned to a few big entities</a></li>
							<li>other classes are less wasteful but still assigned in blocks</li>
							<li>identifying a block's owner can be done through public registries</li>
						</ul>
						<li>IP has <a href="http://en.wikipedia.org/wiki/IPv4_address_exhaustion">(almost) run out of addresses several times</a></li>
						<ul>
							<li>the IP address space has <q>only</q> 4 billion addresses</li>
							<li>because of IP's design, optimal allocation of addresses is not possible</li>
							<li>various fixes have been developed and deployed since the mid-1980's</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>IP Address Problems</title>
					<ul>
						<li>Modern network technologies made IP addresses less reliable</li>
						<ul>
							<li><em>Network Address Translation (NAT)</em> <q>hides</q> device IP addresses to the outside world</li>
							<li><em>Dynamic Host Configuration Protocol (DHCP)</em> makes IP addresses less static</li>
							<li><em>Virtual Private Network (VPN)</em> technology assigns internal addresses for external devices</li>
							<li>phone-based access makes IP addresses only useful on the national level</li>
						</ul>
						<li>IP addresses are still useful as a fallback and for stationary devices</li>
						<ul>
							<li>big organizations often have a well-defined location and IP addresses</li>
							<li>for location on the regional level this often is good enough</li>
						</ul>
						<li>IP addresses are almost useless for phone-based connectivity</li>
						<ul>
							<li>some carriers may support additional technologies (WAP)</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="wifi-positioning">
				<title>Wi-Fi Positioning</title>
				<slide>
					<title>Wi-Fi Networks</title>
					<ul>
						<li>Wi-Fi networks have unique identifiers</li>
						<ul>
							<li><em>Media Access Control (MAC)</em> which uniquely identifies each manufactured device</li>
							<li><em>Service Set Identifier (SSID)</em> which is not unique but publicly visible and reasonably good</li>
						</ul>
						<li>Wi-Fi networks have short range and thus provide good localization</li>
						<ul>
							<li>maximum indoor range of 802.11n is 70m (230ft)</li>
							<li>maximum outdoor range of 802.11n is 250m (820ft)</li>
						</ul>
						<li>Wi-Fi networks are widely deployed and easy to identify/scan</li>
						<ul>
							<li><a href="http://en.wikipedia.org/wiki/Wardriving">Wardriving</a> started the trend of collecting Wi-Fi information</li>
							<li>big databases nowadays contain tens of millions of Wi-Fi networks</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Open Wi-Fi Databases</title>
					<img src="wigle.png" style="height : 65% ; margin : 4% ; " href="http://www.wigle.net/gps/gps/Map/onlinemap2/?maplat=37.819548028632376&amp;maplon=-122.35370635986328&amp;mapzoom=12&amp;startTransID=20010000-00000"/>
				</slide>
			</part>
			<part id="cell-positioning">
				<title>Cell Phone Tower Positioning</title>
				<slide>
					<title>Mobile Internet Access</title>
					<ul>
						<li>Most mobile connectivity nowadays is via cell phone networks</li>
						<ul>
							<li>cell phone technology has had data support for a long time</li>
							<li>WiMax and similar data-centric technologies are not yet widely established</li>
						</ul>
						<li>Localization can differ greatly based on various factors</li>
						<ul>
							<li>cell phone technology (CDMA has wider range than GPS)</li>
							<li>topology (hilly areas require more towers but make localization harder)</li>
							<li>coverage (densely populated areas have more towers)</li>
						</ul>
						<li>For emergency calls localization is required by law</li>
						<ul>
							<li>known as <em href="http://en.wikipedia.org/wiki/Enhanced_911">Enhanced 911 (E911)</em> in the U.S.</li>
							<li>implemented under different names in various other countries</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Location Provider</title>
					<ul>
						<li>Cell phones <q>see</q> various towers</li>
						<ul>
							<li>cell phone tower triangulation can be done with tower IDs</li>
							<li>this requires nothing but the ability to get to tower IDs</li>
						</ul>
						<li>Towers receive traffic from cell phones</li>
						<ul>
							<li><em>Cell of Origin (COO)</em> only use one tower's location</li>
							<li><em>Time Difference of Arrival (TDOA)</em> triangulates between synchronized towers</li>
							<li><em>Angle of Arrival (AOA)</em> allows towers to detect the origin of the signal</li>
							<li>AOA-based localization requires additional equipment in the towers</li>
							<li>AOA-based localization can only be done by the cell phone operator</li>
						</ul>
						<li>Some cell phone operators provide their own location services</li>
						<ul>
							<li>E911 is required by law</li>
							<li>additional services such as <a href="http://products.verizonwireless.com/index.aspx?id=fnd_familylocator_features">Verizon's Family Locator</a></li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="gps">
				<title>Global Positioning System (GPS)</title>
				<slide>
					<title>Military Technology</title>
					<ul>
						<li>Long-range ballistic missiles need global navigation</li>
						<li>Cold war technologies were often visionary and expensive</li>
						<li>GPS was conceived in the mid-1970's and development started soon</li>
						<ul>
							<li>first experimental satellite launched in 1978</li>
							<li>10 experimental satellites were launched to validate the concept</li>
							<li>new generation of satellites launched in 1989</li>
							<li>initial operational capability was achieved in December 1993</li>
							<li><em>Selective Availability (SA)</em> was switched off in 2000</li>
						</ul>
						<li>Satellite-based means global availability</li>
						<ul>
							<li>satellite orbit is 20,200km (12,550 miles)</li>
							<li>signal strength is low and receivers need line of sight</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>GPS Satellite Visibility</title>
					<img src="gps-animation.gif" style="height : 65% ; margin : 4% ; " href="http://en.wikipedia.org/wiki/File:ConstellationGPS.gif"/>
				</slide>
				<slide id="gps-precision">
					<title>GPS Precision</title>
					<ul>
						<li>GPS positioning precision depends on various factors</li>
						<ul>
							<li><em>Selective Availability (SA)</em> was switched off in 2000 (limit to 100m)</li>
							<li>satellite reception quality (15m precision with optimal reception)</li>
						</ul>
						<li>Augmentation services can enhance precision dramatically</li>
						<ul>
							<li><em>WAAS/EGNOS/MSAS</em> achieves precision in the 3m range</li>
							<li><em>Differential GPS (DGPS)</em> achieves sub-meter precision</li>
							<li><em>Nationwide Differential GPS (NDGPS)</em> is a DGS operated by federal agencies</li>
							<li><em>Real-Time Kinematic (RTK)</em> achieves centimeter precision (even in elevation)</li>
						</ul>
						<li><q>Accuracy</q> information given by receivers often is wrong</li>
						<ul>
							<li>it reflects the receiver's local model (satellite reception)</li>
							<li>external influences (distorted signals) can have a strong effect</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>Geolocation API</title>
			<slide>
				<title>Geolocation API Demo</title>
				<listing src="geolocation-demo.html"/>
			</slide>
			<slide>
				<title>Geolocation-Based Image</title>
				<listing src="geolocation-image.html"/>
			</slide>
			<slide>
				<title>WGS84 Coordinates</title>
				<ul>
					<li>GPS-based coordinates have become the <q>norm</q></li>
					<ul>
						<li>globally usable and readily available from GPS receivers</li>
						<li>printed maps start supporting WGS84 coordinates as well</li>
					</ul>
				</ul>
				<pre href="http://www.w3.org/TR/geolocation-API/#position_interface">interface Position {
	readonly attribute Coordinates coords;
	readonly attribute DOMTimeStamp timestamp;
};</pre>
<pre href="http://www.w3.org/TR/geolocation-API/#coordinates_interface">interface Coordinates {
	readonly attribute double latitude;
	readonly attribute double longitude;
	readonly attribute double altitude;
	readonly attribute double accuracy;
	readonly attribute double altitudeAccuracy;
	readonly attribute double heading;
	readonly attribute double speed;
};</pre>
			</slide>
			<slide>
				<title>Geocoding and Reverse Geocoding</title>
				<ul>
					<li>The current API only supports coordinates</li>
					<ul>
						<li><q>civic locations</q> will be supported in the next version</li>
					</ul>
					<li>Geocoding turns locations into coordinates</li>
					<ul>
						<li><q>Berkeley, CA</q> → (37.875733,-122.265092)</li>
					</ul>
					<li>Reverse Geocoding turns coordinates into locations</li>
					<ul>
						<li>(37.875733,-122.265092) → <q>Berkeley, CA</q></li>
					</ul>
					<li>Geocoding is not a simple 1:1 mapping operation</li>
					<ul>
						<li>most locations are not points; they are areas</li>
						<li>most points can be associated with more than one location</li>
					</ul>
					<li><a href="http://www.geonames.org/">Geonames.org</a> provides data and Web services for (reverse) geocoding</li>
					<ul>
						<li><a href="http://ws.geonames.org/findNearby?lat=37.875733&amp;lng=-122.265092">findNearby(37.875733,-122.265092) → <q>Normandy Village</q></a></li>
						<li><a href="http://ws.geonames.org/extendedFindNearby?lat=37.875733&amp;lng=-122.265092">extendedfindNearby(37.875733,-122.265092) → <q>Berkeley, Alameda, California, US</q></a></li>
						<li><a href="http://ws.geonames.org/findNearbyPostalCodes?lat=37.875733&amp;lng=-122.265092">findNearbyPostalCodes(37.875733,-122.265092) → <q>94709, 94704, 94720, 94703, 94708</q></a></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Location Privacy Issues</title>
			<slide>
				<title>Handling Privacy</title>
				<ul>
					<li>Implementation requirements <a href="http://www.w3.org/TR/geolocation-API/#privacy_for_uas">defined in the specification</a></li>
					<ul>
						<li><q>User Agents must not send location information to Web sites without the express permission of the user.</q></li>
						<li><q>User Agents must acquire permission through a user interface, unless they have prearranged trust relationships with users.</q></li>
						<li><q>The user interface must include the URI of the document origin.</q></li>
						<li><q>[…] permissions […] must be revocable and User Agents must respect revoked permissions.</q></li>
					</ul>
					<li>Service requirements <a href="http://www.w3.org/TR/geolocation-API/#privacy_for_recipients">defined in the specification</a></li>
					<ul>
						<li><q>Recipients must only request location information when necessary.</q></li>
						<li><q>Recipients must only use the location information for the task for which it was provided to them.</q></li>
						<li><q>Recipients must dispose of location information once that task is completed, unless expressly permitted to retain it by the user.</q></li>
						<li><q>Recipients must also take measures to protect this information against unauthorized access.</q></li>
						<li><q>If location information is stored, users should be allowed to update and delete this information. </q></li>
					</ul>
					<li>This is essentially <q>opt-out</q>, an <q>opt-in</q> model would have been possible</li>
					<ul>
						<li>configure the requirements when/how location is made available</li>
						<li>allow exceptions if services want to exceed the preferences</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Sensitive Data</title>
				<ul>
					<li>Location data reveals sensitive information</li>
					<ul>
						<li>location data allows to physically locate devices/users</li>
						<li>historical location data can be mined for a lot of information</li>
					</ul>
					<li>Many devices use <em>location providers</em> for determining location</li>
					<ul>
						<li>highly sensitive data flowing in a very distributed scenario</li>
						<li>the term <q>third party</q> often is defined in a very fuzzy way</li>
						<li>the location providers become very powerful information brokers</li>
					</ul>
					<li>Maybe some regulation/legislation will be introduced</li>
					<ul>
						<li>location might be treated as sensitive data (such as medical data)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Location Fuzzing</title>
				<ul>
					<li>Many/most applications do not need GPS precision</li>
					<ul>
						<li>some services have more nuanced models (<a href="http://fireeagle.yahoo.net/">FireEagle</a> provides choice)</li>
					</ul>
					<li>Coordinate-based fuzzing can be attacked more easily</li>
					<ul>
						<li>possible to determine a smaller region given sufficient fuzzed location</li>
					</ul>
					<li>Should there be support for user-specified locations?</li>
					<ul>
						<li>plausible and consistent lying is not easy (but maybe desirable)</li>
						<li>there are numerous useful scenarios for providing <q>false</q> locations</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="localstorage">
		<title short="Storage">Local Storage</title>
		<date>2010-03-05</date>
		<toc class="resources"><a href="http://www.w3.org/TR/webstorage/" title="W3C Web Storage API">Web Storage</a>&#160;· <a href="http://www.w3.org/TR/webdatabase/" title="W3C Web SQL Database API">Web SQL Database</a>&#160;· <a href="http://www.w3.org/2001/tag/doc/state.html" title="State in Web Application Design">State</a>&#160;· <a href="http://tools.ietf.org/html/rfc2965" title="Cookies RFC">Cookies Spec</a></toc>
		<toc class="abstract">Mobile applications face two main challenges that call for local data storage: they must be able to <em>go offline</em> so that they can work when there is no connectivity; they must be able to <em>store data locally</em> so that they can better optimize network traffic. In this lecture, we look some of the established mechanisms for local storage (Cookies) and traffic optimization (HTTP caching), and look at the HTML5 mechanisms that provide more extensive client-side support for local data storage: <em>Web Storage</em> and <em>Web SQL Database</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Optimization and Expansion</title>
			<ul>
				<li>Better local storage allows better data handling</li>
				<ul>
					<li>local HTTP caches are useful but not for everything</li>
					<li>almost every application uses some sort of (local) data storage</li>
				</ul>
				<li>Local storage allows meaningful <link href="offline">offline applications</link></li>
				<ul>
					<li>it is a necessary but not a sufficient condition for offline applications</li>
					<li>for real offline applications both <em>data</em> and <em>code</em> must be offline-enabled</li>
				</ul>
				<li>What kind of data types are required?</li>
				<ul>
					<li><link href="cookies"/> introduced the idea of minimal client-side data (just a session ID)</li>
					<li>more extensive data storage might look for <link href="key-value-storage">key/value storage</link></li>
					<li>advanced client-side data management can benefit from a <link href="relational-storage">structured model and language</link></li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Minimal Web Storage Demo</title>
			<listing src="web-storage-demo.html"/>
		</slide>
		<slide>
			<title>Local Storage vs. Caching</title>
			<ul>
				<li>Local storage is explicitly done by the application</li>
				<ul>
					<li>the application has full control and responsibility</li>
				</ul>
				<li>Caching is transparently done by the local HTTP implementation</li>
				<ul>
					<li>the application has no control or even knowledge</li>
					<li>caching is supposed to work as an optimization</li>
					<li><a href="http://www.w3.org/TR/DataCache/">Programmable HTTP Caching and Serving</a> is interesting but unlikely to happen</li>
				</ul>
				<li>Caching works perfectly for resource-oriented client/server applications</li>
				<ul>
					<li>not all applications are (exclusively) client/server</li>
					<li>many mobile applications are a mix of local logic and client/server logic</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Local Storage vs. Cookies</title>
			<ul>
				<li><link href="cookies"/> are managed through HTTP interactions</li>
				<ul>
					<li>their context is the domain from which they are set</li>
					<li>browsers automatically send a cookie when they contact the server</li>
					<li>servers can set cookies at any time based on their origin</li>
				</ul>
				<li>Cookies are scoped at the browser level</li>
				<ul>
					<li>cookies are managed by and thus identify browsers</li>
					<li><em>tabbed browsing</em> has introduced a different level of granularity</li>
					<li>managing multi-tab sessions requires careful use of cookies</li>
				</ul>
				<li>What is the <q>best scope</q> for client-side state?</li>
				<ul>
					<li>cookies at the browser level are useful for authentication</li>
					<li>cookies at the browser level can be problematic for user interactions</li>
					<li>combining cookies and URI rewriting can be a good approach</li>
				</ul>
			</ul>
		</slide>
		<part id="cookies">
			<title>Cookies</title>
			<slide>
				<title>Tracking Sessions</title>
				<ul>
					<li>Invented as a way to compensate for HTTP's lack of state</li>
					<ul>
						<li>application state is being sent to the client (<http>Set-Cookie</http>)</li>
						<li>the client transmits application state in requests (<http>Cookie</http>)</li>
					</ul>
					<li>Cookies do not contain code that is executed</li>
					<ul>
						<li>some data that represents application state (by value or by reference)</li>
						<li>this data is stored by the client and returned to the server</li>
						<li>the client is not supposed to interpret the data in any way</li>
					</ul>
					<li>Cookies can be used in many different ways</li>
					<ul>
						<li>when used for tracking application state they are unproblematic</li>
						<li>when used for tracking resource state they introduce problems</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Cookies for State Management</title>
				<img style="width : 90% ; margin : 2% ; " src="web-app-cookie-state.png" title="Cookies for State Management"/>
			</slide>
			<slide>
				<title>Cookie Mechanics (Initial Request)</title>
				<listing src="cookie-demo.txt" line="1-28" href="https://www.ischool.berkeley.edu/intranet"/>
			</slide>
			<slide>
				<title>Cookie Mechanics (Authenticating)</title>
				<listing src="cookie-demo.txt" line="32-62" href="https://www.ischool.berkeley.edu/intranet"/>
			</slide>
			<slide>
				<title>Cookie Mechanics (Cookied Repeat)</title>
				<listing src="cookie-demo.txt" line="66-86" href="https://www.ischool.berkeley.edu/intranet"/>
			</slide>
			<part>
				<title>Third-Party Cookies</title>
				<slide>
					<title>Advertising &amp; Privacy</title>
					<ul>
						<li>Big ad servers are digital hubs in the commercial Web</li>
						<ul>
							<li>consumers switch content providers but get the same ad provider</li>
							<li>tracking consumers <em>across</em> content providers is very valuable</li>
						</ul>
						<li>Cookies set by ad providers are sent very frequently</li>
						<ul>
							<li>each site that uses the ad provider triggers the cookies to be sent</li>
							<li>detailed profiling can be employed for creating consumer profiles</li>
						</ul>
						<li>Content and ad providers can cooperate for better profiling</li>
						<ul>
							<li>consumers log in to content providers and are reliably identified</li>
							<li>their personal profile can be matched with the ad provider's profile</li>
							<li>ad provider consolidation makes this scenario realistic</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Browsers Assemble Web Pages</title>
					<p>Typical Web resources (HTML pages) are assembled from a number of resources retrieved by HTTP. Any resource not originating on the server that is hosting the HTML page is considered a <q>third-party resource</q>. If the HTTP response for such a resource contains a cookie, it is a <q>third-party cookie</q>.</p>
					<img style="width : 90% ; margin : 2% ; " src="third-party-cookie.png" title="Third Party Cookie"/>
				</slide>
				<slide>
					<title>The World's Most Popular Script</title>
					<pre href="http://www.google-analytics.com/ga.js">&lt;script type="text/javascript">
	var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
	document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
&lt;/script>
&lt;script type="text/javascript">
	try {
		var pageTracker = _gat._getTracker("UA-xxxxxx-x");
		pageTracker._trackPageview();
	} catch(err) {}
&lt;/script></pre>
					<listing src="ga.js" line="443-452" title="GA Web Bug"/>
				</slide>
			</part>
		</part>
		<part id="key-value-storage">
			<title>Key/Value Storage</title>
			<slide>
				<title>Limitations of Cookies</title>
				<ul>
					<li>Cookies are designed to work without client-side scripting</li>
					<li>Cookie storage space is limited (<a href="http://www.apps.ietf.org/rfc/rfc2965.html">RFC 2965</a> makes <a href="http://www.apps.ietf.org/rfc/rfc2965.html#sec-5.3">recommendations</a>)</li>
					<ul>
						<li>at least 300 cookies</li>
						<li>at least 4096 bytes per cookie</li>
						<li>at least 20 cookies per unique host or domain name</li>
					</ul>
					<li>Cookies are <em>browser-scoped</em>, not <em>tab-scoped</em></li>
					<ul>
						<li>many applications do not work well when used in multiple tabs</li>
						<li>cookie-based interactions implicitly interact <q>between tabs</q></li>
						<li><link href="session-storage"/> allows local storage to be scoped by session</li>
					</ul>
					<li>Cookies are transmitted with each interaction (HTTP mechanism)</li>
					<ul>
						<li>browser manage <q>cookie storage space</q> automatically</li>
						<li>cookies should be small (implementation limits and HTTP overhead)</li>
						<li><link href="local-storage"/> allows local storage to be managed by scripting</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Simple Storage Interface</title>
				<ul>
					<li><em>Scope</em> is determined by document origin</li>
					<ul>
						<li>access control based on the same concepts as other Web technologies</li>
						<li>handles <q>sessions</q> as well as (some) access control</li>
					</ul>
					<li>Storage is organized as a list of key/value pairs</li>
					<ul>
						<li>there can only be one value per key (<em>identification</em> by key)</li>
					</ul>
					<li>Order is defined but not stable across changes</li>
					<ul>
						<li>items can be requested by position (useful for scanning all items)</li>
						<li>order can change when items are added or removed</li>
					</ul>
				</ul>
				<pre href="http://www.w3.org/TR/webstorage/#the-storage-interface">interface Storage {
	readonly attribute unsigned long length;
	getter DOMString key(in unsigned long index);
	getter any getItem(in DOMString key);
	setter creator void setItem(in DOMString key, in any data);
	deleter void removeItem(in DOMString key);
	void clear();
};</pre>
			</slide>
			<part id="session-storage">
				<title>Session Storage</title>
				<slide>
					<title>Storage per Top-Level Browsing Context</title>
					<ul>
						<li>Session storage is scoped by two mechanisms</li>
						<ul>
							<li>one session storage per <a href="http://www.w3.org/TR/html5/browsers.html#origin-0">document origin</a></li>
							<li>one session storage for <a href="http://www.w3.org/TR/html5/browsers.html#windows">top-level browsing context</a></li>
						</ul>
						<li>Session storage behaves in the same way as local storage</li>
						<ul>
							<li>only the scoping (and thus persistence) is different</li>
						</ul>
						<li>Session storage changes are indicated by <html href="http://www.w3.org/TR/webstorage/#the-storage-event">storage</html> events</li>
						<ul>
							<li>applications can install and implement storage event handlers</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="local-storage">
				<title>Local Storage</title>
				<slide>
					<title>Storage per Browser</title>
					<ul>
						<li>Local storage is scoped by one mechanism</li>
						<ul>
							<li>one local storage per <a href="http://www.w3.org/TR/html5/browsers.html#origin-0">document origin</a></li>
						</ul>
						<li>Local storage behaves in the same way as session storage</li>
						<ul>
							<li>only the scoping (and thus persistence) is different</li>
						</ul>
						<li>Local storage changes are indicated by <html href="http://www.w3.org/TR/webstorage/#the-storage-event">storage</html> events</li>
						<ul>
							<li>applications can install and implement storage event handlers</li>
							<li>event handlers are more important for local storage (multiple tabs)</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part id="relational-storage">
			<title>Relational Storage</title>
			<slide>
				<title>Local SQL Database</title>
				<img src="sqlite.gif" style="float : right ; margin : 0 1em 2em 2em ; width : 20% " href="http://www.sqlite.org/"/>
				<ul>
					<li>Browsers often have built-in databases</li>
					<ul>
						<li>managing fast access to history information</li>
						<li>managing caching and other internal data structures</li>
					</ul>
					<li><q>Local applications</q> often have sophisticated storage needs</li>
					<ul>
						<li>relational storage is the most mainstream data metamodel</li>
						<li>allowing scripting to access relational storage open new opportunities</li>
					</ul>
					<li>Browser databases are not always exposed to scripting</li>
					<ul>
						<li><a href="http://www.sqlite.org/">SQLite</a> is included in Firefox and WebKit (and <a href="http://www.sqlite.org/famous.html">many other products</a>)</li>
						<li>Firefox has decided to only allow access for add-ons (e.g., <a href="http://www.zotero.org/">Zotero</a>)</li>
						<li>WebKit exposes database access to scripts as the <a href="http://www.w3.org/TR/webdatabase/">Web SQL Database</a> API</li>
					</ul>
				</ul>
			</slide>
		<slide>
			<title>Minimal Web Database Demo (Create Tables)</title>
			<listing src="web-database-demo.html" line="6-28" href="http://www.experimenting.in/other/demo_websql.htm"/>
		</slide>
		<slide>
			<title>Minimal Web Database Demo (Use Tables)</title>
			<listing src="web-database-demo.html" line="59-70" href="http://www.experimenting.in/other/demo_websql.htm"/>
			<listing src="web-database-demo.html" line="98-106" href="http://www.experimenting.in/other/demo_websql.htm"/>
		</slide>
		<slide>
			<title>Minimal Web Database Demo (Join Tables)</title>
			<listing src="web-database-demo.html" line="84-95" href="http://www.experimenting.in/other/demo_websql.htm"/>
		</slide>
			<slide>
				<title>Specification Problems</title>
				<ul>
					<li><q href="http://www.w3.org/TR/webdatabase/#web-sql">User agents must implement the SQL dialect supported by SQLite 3.6.19</q></li>
					<ul>
						<li>not acceptable as a Web standard</li>
						<li>defining a reasonable and useful subset of SQL is not easy</li>
					</ul>
					<li>Currently only usable for targeted development</li>
					<ul>
						<li>supported by some major browsers (WebKit, maybe Opera)</li>
						<li>not supported by other major browsers (Firefox, IE)</li>
						<li>will probably be changed if it ever becomes a standard</li>
					</ul>
					<li><link href="key-value-storage"/> is the <q>better</q> solution for storage</li>
				</ul>
			</slide>
		</part>
		<slide>
			<title>Conclusions</title>
			<ul>
				<li>Walking the line between <q>local application</q> and <q>Web UI</q> can be challenging</li>
				<li>Good online <em>and</em> offline capabilities are not easy to design/build</li>
				<li>Local storage provides some interesting additional functionality</li>
				<li>Maybe Web frameworks will start providing support for <q>syncing</q></li>
				<li>Current technologies provide very basic support but no useful patterns</li>
			</ul>
		</slide>
	</presentation>
	<presentation id="serverside">
		<title short="Server Side">Server Side Technologies</title>
		<date>2010-03-08</date>
		<toc class="resources"><a href="http://www.php.net/">PHP</a>&#160;· <a href="http://simplepie.org/">SimplePie</a></toc>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Adapting Content for mobileOK Devices">A5: mobileOK</a> (assigned: 3/8; due: 3/19)</toc>
		<toc class="abstract">Navigating the mobile landscape means that depending on the targeted mobile devices, it might be impossible to rely on sophisticated client-side support for Web technologies. In such a case, it is necessary to move the functionality to the server-side, so that mobile applications can be used by simpler clients as well. In this lecture, we look at the concepts that can be utilized on the server side, <em>standalone web servers</em>, <em>general programming frameworks</em>, and <em>Content Management Systems (CMS)</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Mobile Applications</title>
			<ul>
				<li>Mobile applications use one of three designs:</li>
			</ul>
			<ol>
				<li>Local application only</li>
				<ul>
					<li>games and navigation and personal productivity applications</li>
					<li>more and more of those local applications have online features as well</li>
				</ul>
				<li>Server-side application only</li>
				<ul>
					<li>functionality and data is entirely implemented and exposed server-side</li>
					<li>most Web-based applications qualify</li>
					<li>RIAs (Flash/Silverlight/HTML5) are supporting more local functionality</li>
				</ul>
				<li>Mix of local and server-side functionality</li>
				<ul>
					<li>local capabilities compensate for disconnects and slow transfer rates</li>
					<li>server-side capabilities compensate for limited devices and risk of data loss</li>
					<li>well-designed switching between both modes is useful but not easy</li>
					<li>good developer support for this type is in its infancy</li>
				</ul>
			</ol>
		</slide>
		<part id="web-server">
			<title>Web Server</title>
			<slide>
				<title>Computing Cycles</title>
				<ul>
					<li>Mainframes started as server-side and dumb terminals</li>
					<li>PCs took over as cheaper alternatives and <q>local-only</q></li>
					<li><q>Client/Server Computing</q> combined PCs and central servers</li>
					<li><q href="http://en.wikipedia.org/wiki/Thin_client">Thin Clients</q> were providing display services only (<a href="http://en.wikipedia.org/wiki/X_Window_System">X11</a>)</li>
					<li><q>Web Clients</q> were a better implementation of the <q>thin client</q> idea</li>
					<ul>
						<li>display and local capabilities may look similar to dumb terminals</li>
						<li>the architectural principle changed and is very different (<link href="rest">REST</link>)</li>
					</ul>
					<li><q>Rich Internet Applications</q> move more functionality to the client</li>
					<ul>
						<li>HTML5 is the latest <q>fat client</q> development</li>
					</ul>
					<li>Mobile Applications require specific design considerations</li>
					<ul>
						<li>scripting code runs about a hundred times slower than on a desktop</li>
						<li>online/offline support and standalone mode are essential features</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP and File Systems</title>
				<ul>
					<li>HTTP servers read content from file systems</li>
					<ul>
						<li>this is the simplest possible setup (static content in files)</li>
						<li>content also can be post-processed by the server</li>
						<li>content can be dynamically created by a program</li>
					</ul>
					<li>Server-side and client-side always is a trade-off</li>
					<ul>
						<li>server-side solutions are slower (round-trip) and less elegant</li>
						<li>client-side solutions depend on client capabilities</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Serving Content from Files</title>
				<img style="width : 90% ; margin : 2% ; " src="wcms-fs-only.png"/>
			</slide>
			<slide>
				<title>Serving Content from Files with SSI</title>
				<img style="width : 90% ; margin : 2% ; " src="wcms-fs-ssi.png"/>
			</slide>
			<slide id="ssi">
				<title short="SSI">Server-Side Includes (SSI)</title>
				<ul>
					<li>Simple server-side processing</li>
					<ul>
						<li>add the modification date of the file</li>
						<li>include another file</li>
					</ul>
					<li>Minor extensions cover conditional processing</li>
					<ul>
						<li>conditional statements for request-specific processing</li>
					</ul>
					<li>Depends on server type and setup</li>
					<ul>
						<li>enabled by default in most Apache configurations</li>
					</ul>
					<li>Ability to execute external programs (started via <link href="cgi">CGI</link>)</li>
				</ul>
			</slide>
			<slide id="cgi">
				<title short="CGI">Common Gateway Interface (CGI)</title>
				<img style="float : right ; margin : 0 1em 2em 2em ; width : 20% " src="http://radblast-aa.wunderground.com/cgi-bin/radar/WUNIDS_map?station=MUX&amp;brand=wui&amp;num=6&amp;delay=15&amp;type=N0R&amp;frame=0&amp;scale=0.498&amp;noclutter=0&amp;t=1165711666&amp;lat=37.86912155&amp;lon=-122.26962280&amp;label=Berkeley%2C+CA&amp;showstorms=0&amp;map.x=400&amp;map.y=240&amp;centerx=470&amp;centery=334&amp;transx=70&amp;transy=94&amp;showlabels=1&amp;severe=0&amp;rainsnow=1&amp;lightning=0" />
				<ul>
					<li>Protocol for connecting programs with Web servers</li>
					<ul>
						<li>rules for how information about the request is handed to the <q>script</q></li>
						<li>rules for how the result of the <q>script</q> is handed to the server</li>
					</ul>
					<li>CGI can be embedded into pages or produce complete pages</li>
					<ul>
						<li>embedded CGI results are expected to produce HTML fragments</li>
						<li>complete CGI results are expected to produce complete HTML content</li>
						<li><code href="http://radblast-aa.wunderground.com/cgi-bin/radar/WUNIDS_map?station=MUX&amp;brand=wui&amp;num=6&amp;delay=15&amp;type=N0R&amp;frame=0&amp;scale=0.498&amp;noclutter=0&amp;t=1165711666&amp;lat=37.86912155&amp;lon=-122.26962280&amp;label=Berkeley%2C+CA&amp;showstorms=0&amp;map.x=400&amp;map.y=240&amp;centerx=470&amp;centery=334&amp;transx=70&amp;transy=94&amp;showlabels=1&amp;severe=0&amp;rainsnow=1&amp;lightning=0">http://radblast-aa.wunderground.com/cgi-bin/radar/WUNIDS_map?station=MUX&amp;brand=wui&amp;num=6&amp;delay=15&amp;type=N0R&amp;frame=0&amp;scale=0.498&amp;noclutter=0&amp;t=1165711666&amp;lat=37.86912155&amp;lon=-122.26962280&amp;label=Berkeley%2C+CA&amp;showstorms=0&amp;map.x=400&amp;map.y=240&amp;centerx=470&amp;centery=334&amp;transx=70&amp;transy=94&amp;showlabels=1&amp;severe=0&amp;rainsnow=1&amp;lightning=0</code></li>
					</ul>
					<li>CGI is not always a good solution for heavy load servers</li>
					<ul>
						<li>the external program is started every time a request is processed</li>
						<li>the overhead depends on the type of CGI <q>script</q></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Server Side Programming</title>
			<slide>
				<title>From Processing to Programming</title>
				<ul>
					<li>PHP started as a simple inclusion processor</li>
					<ul>
						<li><em>Personal Home Page</em> reflects the original goal as a simple site management tool</li>
						<li><em>PHP: Hypertext Processor</em> reflects the more generalized approach of PHP today</li>
					</ul>
					<li>Functionality was added incrementally</li>
					<ul>
						<li>recent versions of PHP turn it into a complete programming language</li>
						<li>the <q>design</q> of the language is more pragmatic than elegant</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>PHP Hello World</title>
				<listing src="hello-world.php"/>
			</slide>
			<slide>
				<title>Minimal Server-Side Feed Reader</title>
				<listing src="feed-demo.php" href="src/feed-demo.php?feed=http://dret.typepad.com/dretblog/atom.xml"/>
			</slide>
			<slide>
				<title>Adding jQuery</title>
				<listing src="feed-demo-jquery.php" href="src/feed-demo-jquery.php?feed=http://dret.typepad.com/dretblog/atom.xml"/>
			</slide>
		</part>
		<part id="cms">
			<title short="CMS">Content Management System (CMS)</title>
			<title>Content on the Web</title>
			<slide>
				<title>Content and Structure</title>
				<ul>
					<li>Content is what matters most</li>
					<ul>
						<li>content itself often has some internal structure</li>
						<li>content may explicitly link to other content</li>
					</ul>
					<li>Macro-structure often is more representation than content</li>
					<ul>
						<li>displaying the current context of the content</li>
						<li>displaying related content</li>
						<li>displaying some overall structure (site navigation)</li>
					</ul>
					<li>Content often is reusable across application scenarios</li>
					<ul>
						<li>publishers have used <em>Content Management Systems</em> for a long time</li>
						<li>adding a new publication channel to a CMS should be evolutionary</li>
					</ul>
					<li>Content may require very different support depending on the channel</li>
					<ul>
						<li>newspapers need fine-tuned layout and good control over content size</li>
						<li>Web needs good interlinking and navigation</li>
					</ul>
				</ul>
			</slide>
			<slide id="cms-evolution">
				<title>CMS Evolution</title>
				<ol>
					<li>Web servers reading from files</li>
					<li>Web servers implementing primitive content management (SSI)</li>
					<li>Scripting languages implementing better management</li>
					<li>Management code getting hooked up to databases</li>
					<li>Better handling of client-specific behavior</li>
					<li>Databases getting more diverse (RDB, XML, RDF)</li>
				</ol>
			</slide>
			<slide>
				<title>The Rise of the CMS</title>
				<ul>
					<li>File-based content management works well for small sites</li>
					<ul>
						<li>simple site structure and small number of files</li>
						<li>redundant parts can be manually synchronized</li>
						<li>no software is required other than a Web server</li>
					</ul>
					<li>Web servers soon developed rudimentary CMS functions (<a href="http://httpd.apache.org/docs/2.2/howto/ssi.html" title="Server Side Includes">SSI</a>)</li>
					<ul>
						<li>rudimentary support is better than no support</li>
						<li>managing a non-trivial setup with SSI still is a challenge</li>
						<li>SSI allows includes but no backlinks and thus hides dependencies</li>
					</ul>
					<li>Content management is similar to code management</li>
					<ul>
						<li>simple setups require no or little tool support</li>
						<li>serious projects need tools to manage dependencies and changes</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>File Systems are Databases</title>
				<ul>
					<li>A file system is a simple hierarchical database</li>
					<ul>
						<li>it does not know data types and simply stores any content</li>
						<li>its structure is a tree with a few extra tricks (such as symlinks)</li>
					</ul>
					<li>Many scenarios have much more structured data models</li>
					<ul>
						<li>products, people, financial institutions all have complex data models</li>
						<li>content should be stored and queried based on these models</li>
					</ul>
					<li>Databases are better optimized for storing structured content</li>
					<ul>
						<li>better methods for structured storage and retrieval</li>
						<li>better strategies for managing large datasets</li>
						<li>sophisticated tools for access control, backup, and versioning</li>
					</ul>
				</ul>
			</slide>
			<slide id="content-tables">
				<title>Tables (Relational Model)</title>
					<ul>
						<li>Most widely used model for large collections of structured data</li>
						<li>Very mature products and many skilled people available</li>
						<li>The biggest advantage is that it is not hierarchical (no structure bias)</li>
						<li>Advantages of relations:</li>
						<ul>
							<li>well-understood model and maps well to existing data</li>
							<li>the non-hierarchical model allows views from different perspectives</li>
							<li>highly scalable solutions available</li>
						</ul>
						<li>Disadvantages of Relations:</li>
						<ul>
							<li>bad for sequences and variable structures (choices, repetitions, …)</li>
							<li>very bad for structured documents</li>
						</ul>
					</ul>
			</slide>
			<slide>
				<title>ER Model</title>
				<img style="height : 70% ; margin : 2% ; " src="ER-Diagram.png" href="http://en.wikipedia.org/wiki/Entity-relationship_model" title="Wikipedia: Entity-Relationship Model"/>
			</slide>
			<slide id="content-xml">
				<title>Ordered Trees (XML)</title>
					<ul>
						<li><link href="xml">XML</link> has a heritage of document processing</li>
						<li>XML tools can be used standalone and are widely supported</li>
						<li>XML and HTML have a very similar foundation</li>
						<li>XML has two built-in directions: hierarchy and ordered children</li>
						<li>Advantages of XML:</li>
						<ul>
							<li>maps well to HTML and XHTML</li>
							<li>well-suited for document-oriented content</li>
						</ul>
						<li>Disadvantages of XML:</li>
						<ul>
							<li>not good at representing non-tree data</li>
							<li>databases not as mature as relational products</li>
						</ul>
					</ul>
			</slide>
			<slide>
				<title>XML Content</title>
				<p>The term <em>Mixed content</em> in XML refers to elements <a href="http://www.w3.org/TR/xml/#sec-mixed-content">which have text content mixed with elements</a>. What these elements do depends on the elements <img style="height : 1em" src="smiley.gif"/>, but the important point is that they are on the same level as the text nodes of the mixed content.</p>
				<img style="width : 90% ; margin : 4% ;" src="mixed-content.png" title="XML tree for mixed content"/>
			</slide>
			<slide id="content-rdf">
				<title>Directed Graphs (RDF)</title>
					<ul>
						<li>RDF is the metamodel of the <a href="../web-fall09/semweb">Semantic Web</a></li>
						<li>Highly granular, less rigid than tables, less ordered than trees</li>
						<li>Advantages of RDF:</li>
						<ul>
							<li>any structure can be mapped to RDF triples</li>
							<li>support still limited but getting better</li>
						</ul>
						<li>Disadvantages of RDF:</li>
						<ul>
							<li>no model for document boundaries and self-contained units</li>
							<li>bad for sequences</li>
							<li>very bad for structured documents</li>
						</ul>
					</ul>
			</slide>
		</part>
	</presentation>
    <presentation id="rest">
        <title short="REST">Representational State Transfer (REST)</title>
        <date>2010-03-10</date>
        <toc class="reading"><a href="http://www.eioba.com/a69755/how_i_explained_rest_to_my_wife">What is REST?</a>&#160;· <a href="http://bitworking.org/news/193/Do-we-need-WADL">REST Interfaces</a></toc>
        <toc class="resources"><a href="http://www.mulberrytech.com/Extreme/Proceedings/html/2002/Prescod01/EML2002Prescod01.html" title='P. Prescod, "Roots of the REST/SOAP Debate", Extreme Markup Languages Conference, August 2002'>REST vs. SOAP</a>&#160;· <a href="http://rest.blueoxen.net/cgi-bin/wiki.pl">RESTwiki</a></toc>
        <toc class="abstract"><em>Representational State Transfer (REST)</em> is an architectural style for building distributed systems. The Web is an example for such a system. REST-style applications can be built using a wide variety of technologies. REST's main principles are those of resource-oriented states and functionalities, the idea of a unique way of identifying resources, and the idea of how operations on these resources are defined in terms of a single protocol for interacting with resources. REST-oriented system design leads to systems which are open, scalable, extensible, and easy to understand.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>The Web as a System</title>
			<ul>
				<li>The Web is one distributed hypermedia system</li>
				<ul>
					<li>the main architectural components are URIs, HTTP, and HTML</li>
					<li>all other Web technologies are built on that foundation</li>
					<li>if they are not, they are very likely not well-designed Web technologies</li>
				</ul>
				<li>The Web is amazingly open, scalable, extensible, and easy to understand</li>
				<ul>
					<li><em>openness</em> allows new technologies to be introduced</li>
					<li><em>scalability</em> ensures that the system does not contain bottlenecks</li>
					<li><em>extensibility</em> allows the Web to evolve without any redesign of existing parts</li>
					<li><em>simplicity</em> makes sure that the system survives and evolves</li>
				</ul>
				<li>No other information system gets even close to the Web</li>
				<ul>
					<li>but not all information system designs can accept the Web's limitations</li>
					<li>REST should be seen as a guideline how to build a true Web application</li>
					<li>other applications will continue to be built using other approaches</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Web System Design</title>
			<blockquote>There are two ways of constructing a software design: One way is to make it so simple that there are <em>obviously</em> no deficiencies, and the other way is to make it so complicated that there are no <em>obvious</em> deficiencies. The first method is far more difficult.</blockquote>
			<p class="quotenote"><a href="http://en.wikipedia.org/wiki/Charles_Antony_Richard_Hoare">C. A. R. Hoare</a>, <a href="http://dret.net/biblio/reference/hoa81"><q>The Emperor's Old Clothes</q>, 1980 Turing Award Lecture</a></p>
		</slide>
		<part>
			<title>Technologies and Implementations</title>
			<slide>
				<title>Object-Orientation</title>
				<ul>
					<li>Object-Orientation is a <em>Software Engineering Style</em></li>
					<ul>
						<li>it can be applied to any programming language</li>
						<li>depending on the language, this is more or less easy</li>
						<li>OO languages support or even enforce certain design patterns</li>
						<li><em>spaghetti code</em> can be written in every programming language</li>
					</ul>
					<li>Implementations can always be bad or good</li>
					<ul>
						<li>the quality of the implementation depends on the programmer</li>
						<li>programmers can be better supported and controlled with an OO language</li>
						<li>implementation quality metrics must be based on the product, not the language</li>
					</ul>
					<li>Good programmers always produce good code</li>
					<li>Bad programmers always produce bad code</li>
					<li>Average programmers need good tools to produce good code</li>
				</ul>
			</slide>
			<slide>
				<title>Technologies are Tools</title>
				<ul>
					<li>Technologies help solving problems</li>
					<ul>
						<li>they are built with certain goals in mind</li>
						<li>they specialize in solving a problem <em>in a specific way</em></li>
					</ul>
					<li>Technology choices are very important</li>
					<ul>
						<li>the technology (i.e., the tool) shapes the way a problem is solved</li>
						<li>working <q>against</q> the tool is possible, but hard and rarely done</li>
					</ul>
					<li>Technologies sometimes cloud the more important issues</li>
					<ol>
						<li>the problem must be well-defined and fully understood</li>
						<li>the general approach to solve a problem must be identified</li>
						<li>finally, a technology supporting this approach must be chosen</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Implementations are Products</title>
				<ul>
					<li>Implementations are built on (and shaped by) technologies</li>
					<li>Implementation = Concepts + Technologies</li>
					<li>Implementation quality depends on both factors</li>
					<ul>
						<li>the right choice of technologies is very important</li>
						<li>the responsible use of that foundation is equally important</li>
					</ul>
					<li>Good REST is as hard to grasp as good OO</li>
					<ul>
						<li>products may claim that they are REST/OO</li>
						<li>they may even use technologies which support REST/OO</li>
						<li>only careful inspection reveals the truth of this claim</li>
						<li>in most cases, this only happens when the product needs to be changed</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="rest-principle">
			<title>REST Principles</title>
			<slide>
				<title>Definition</title>
				<ul>
					<li>Resources are defined by URIs</li>
					<li>Resources are manipulated through their representations</li>
					<li>Messages are self-descriptive and stateless</li>
					<li>There can be multiple representations for a resource</li>
					<li>Application state is driven by resource manipulations</li>
				</ul>
			</slide>
			<slide>
				<title>Resources</title>
				<ul>
					<li>Resources are defined by URIs</li>
					<ul>
						<li>resources can never be accessed or manipulated directly</li>
						<li>REST works with resource representations</li>
					</ul>
					<li>Resources are all the things we want to work with</li>
					<ul>
						<li>if you cannot name something, you cannot do anything with it</li>
						<li>a popular resource type on the Web are documents</li>
						<li>documents usually are a structured collection of information</li>
					</ul>
					<li>Documents are abstract concepts of descriptive resources</li>
					<ul>
						<li>they may be used in different contexts (e.g., formats)</li>
						<li>different applications may be interested in different representations</li>
						<li>the underlying resource is always the same</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>State</title>
				<ul>
					<li>State is represented as part of the content being transferred</li>
					<ul>
						<li>server interruptions do not create problems for the client</li>
						<li>it is possible to switch between servers for different interactions</li>
						<li>clients can simply store the representation to save the state</li>
					</ul>
					<li>State transfer makes the system scalable</li>
					<ul>
						<li>data transfer is not state-specific (no stateful connection handling)</li>
						<li>state is transferred between client and server</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Establishing a Common Model</title>
				<ul>
					<li>Distributed systems must be based on a shared model</li>
					<ul>
						<li>traditional systems must agree on a common API</li>
						<li>REST systems structure agreement into three areas</li>
					</ul>
					<li>REST is built around the idea of simplifying agreement</li>
					<ul>
						<li><em>nouns</em> are required to name the resources that can be talked about</li>
						<li><em>verbs</em> are the operations that can be applied to named resources</li>
						<li><em>content types</em> define which information representations are available</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Nouns</title>
				<ul>
					<li>Nouns are the names of resources</li>
					<ul>
						<li>in most designs, these names will be URIs</li>
						<li>URI design is a very important part of a REST-based system design</li>
					</ul>
					<li>Everything of interest should be named</li>
					<ul>
						<li>by supporting well-designed names, applications can talk about named things</li>
						<li>new operations and representations can be introduced</li>
					</ul>
					<li>Separating nouns from verbs and representations improves extensibility</li>
					<ul>
						<li>applications might still work with resources without being able to process them</li>
						<li>introducing new operations on the Web does not break the Web</li>
						<li>introducing new content types on the Web does not break the Web</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Verbs</title>
				<ul>
					<li>Operations which can be applied to resources</li>
					<li>The core idea of REST is to use <em>universal verbs</em> only</li>
					<ul>
						<li>universal verbs can be applied to all nouns</li>
					</ul>
					<li>For most applications, HTTP's basic methods are sufficient</li>
					<ul>
						<li><http>GET</http>: Fetching a resource (there must be no side-effects)</li>
						<li><http>PUT</http>: Transfers a resource to a server (overwriting if there already is one)</li>
						<li><http>POST</http>: Adds to an existing resource on the server</li>
						<li><http>DELETE</http>: Discards a resource (its name cannot be used anymore)</li>
					</ul>
					<li>Corresponding to the most popular basic database operations</li>
					<ul>
						<li>CRUD: Create, Read, Update, Delete</li>
					</ul>
				</ul>
			</slide>
			<slide id="http-post">
				<title><http>POST</http>ing</title>
				<ul>
					<li><http>POST</http> adds instead of an overwriting update</li>
					<li><http>POST</http> can have different effects</li>
					<ul>
						<li>by <http>POST</http>ing, state is changed and a new resource is created</li>
						<li>by <http>POST</http>ing, only the existing resource is changed</li>
						<li>the server signals the difference using HTTP responses (<http>200 OK</http> or <http>201 Created</http>)</li>
					</ul>
					<li>This is a <em>design choice</em></li>
					<ul>
						<li>if the added information needs to be accessible individually, create a new resource</li>
						<li>for changes of an existing resource, no new resource has to be created</li>
					</ul>
					<li>Make sure that resources are navigable using URIs</li>
					<ul>
						<li>if appropriate, a relationship can be represented in the resource format</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Content Types</title>
				<ul>
					<li>Representations should be machine-processable</li>
					<ul>
						<li>they don't have to, they may be opaque to applications</li>
						<li>in many cases, machine-processable representations are advantageous</li>
					</ul>
					<li>Resources are abstractions, REST passes representations around</li>
					<ul>
						<li>resources can have various representations (i.e., content types)</li>
						<li>clients can request content types they are interested in</li>
					</ul>
					<li>Adding or changing content types does not change the system architecture</li>
					<ul>
						<li>different clients and servers support different content types</li>
						<li><link href="http-conneg"/> allows content types to be negotiated dynamically</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>REST vs. <q>Web Services</q></title>
				<ul>
					<li>REST is a description of the Web's design principles</li>
					<ul>
						<li>it is not something new, it is simply a systematic view of the Web</li>
						<li>REST's claim is to be able to learn from the Web's success</li>
					</ul>
					<li>Web Services (the SOAP flavor) do not build on REST</li>
					<ul>
						<li>they use HTTP as a transport protocol</li>
						<li>they re-create Web functionality through additional specifications (WS-*)</li>
						<li>they have been built by programmers using a top-down approach</li>
					</ul>
					<li>REST and Web Services have different design approaches</li>
					<ul>
						<li>REST starts at the resources and takes everything from there</li>
						<li>Web Services focus on messages, which in most cases are operations</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="rest-implementation">
			<title>REST Implementation</title>
			<slide>
				<title>REST Technologies</title>
				<ul>
					<li>REST is not tied to a particular set of technologies</li>
					<ul>
						<li><link href="rest-uri"/> are the most common choice for nouns</li>
						<li><link href="rest-http"/> methods are the most common choice for verbs</li>
						<li><link href="rest-xml"/> is the most common choice for content types</li>
					</ul>
					<li>Choosing other technologies should have a very good reason</li>
					<ul>
						<li>building a REST system should make it open and accessible</li>
						<li>technology choices are as important as architectural choices</li>
					</ul>
				</ul>
			</slide>
			<slide id="rest-uri">
				<title>URIs</title>
				<ul>
					<li>REST requires a lot of URI design</li>
					<ul>
						<li>instead of being generated as a side-effect, they are the core of the system</li>
					</ul>
					<li>Designing URIs and starting from them is a new way of thinking</li>
					<ul>
						<li>URIs are much more powerful than just being an address of a Web page</li>
					</ul>
					<li>URIs are names for concepts</li>
					<ul>
						<li>concepts are never transmitted, only their representation</li>
						<li>having to focus on concepts rather than representations is helpful</li>
					</ul>
				</ul>
			</slide>
			<slide id="rest-http">
				<title>HTTP</title>
				<ul>
					<li>HTTP is the most successful RESTful protocol</li>
					<ul>
						<li>HTTP's author Roy Fielding coined the term <q>REST</q> in his <a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">Ph.D. thesis</a></li>
					</ul>
					<li>HTTP should be regarded as an <q>application-level protocol</q></li>
					<ul>
						<li>Web Service technologies use HTTP as a transport protocol</li>
						<li>HTTP has much more to offer than a firewall-penetrating pipe</li>
					</ul>
					<li>Web infrastructure is built around proper HTTP usage</li>
					<ul>
						<li>caching is built into HTTP and caches optimize the Web transparently</li>
						<li>authentication can be done using HTTP's authentication methods</li>
						<li>secure data transfer can be done using <link href="https">HTTPS</link></li>
					</ul>
				</ul>
			</slide>
			<slide id="rest-xml">
				<title>XML</title>
				<ul>
					<li>URI-identified resources are abstract concepts</li>
					<ul>
						<li>for machine-based processing, XML is a good representation</li>
						<li>for human-oriented interactions, HTML probably is a better choice</li>
					</ul>
					<li>Connections to other resources must be done by URI</li>
					<ul>
						<li>XML does not make built-in assumptions about identifiers</li>
						<li>but it does support URIs, for example with <em>XInclude</em> and <em>XML Base</em></li>
						<li>RESTful applications are about navigating a Web of URI-identified resources</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Better Services</title>
				<ul>
					<li>REST is an architectural style</li>
					<ul>
						<li>URI/HTTP/HTML/XML may be replaced</li>
						<li>the general principle of resource-based interaction remains valid</li>
					</ul>
					<li>RESTful system designs can create better systems</li>
					<ul>
						<li>a little bit more design effort in the beginning</li>
						<li>a lot less headaches later</li>
					</ul>
					<li>SOA often are not really RESTful</li>
					<ul>
						<li>SOA often focuses on operations</li>
						<li>REST focuses on resources</li>
					</ul>
				</ul>
			</slide>
		</part>
    </presentation>
	<presentation id="offline">
		<title short="Offline">Offline-Capable Applications</title>
		<date>2010-03-15</date>
		<toc class="reading"><a href="http://building-iphone-apps.labs.oreilly.com/ch06.html" title="Building iPhone Apps with HTML, CSS, and JavaScript; Chapter 6: Going Offline">Going Offline</a></toc>
		<toc class="resources"><a href="http://www.w3.org/TR/offline-webapps/" title="W3C Note: Offline Web Applications">Offline Applications</a>&#160;· <a href="http://www.w3.org/TR/html5/offline.html" title="HTML5 Spec: Offline Web Applications">HTML5</a></toc>
		<toc class="assignment"></toc>
		<toc class="abstract">Mobile settings should not rely on the client being online all the time. For Web-based applications, however, this is a challenge, because the traditional model of Web-based applications has no notion of <q>offline mode</q>. HTML5, however, introduces the ability to design and build offline-capable applications. One important part of that is <em>local storage</em>, the ability to persistently store data on the client. The other important part is the <em>application cache</em>, the ability of a Web-based application to list all the resources that are necessary for offline mode. Clients can then reliably store all these files locally for offline capabilities.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Webless Web-Based Applications</title>
			<slide>
				<title>Limitations of Web-based Applications</title>
				<ul>
					<li>Limited access to device hardware</li>
					<ul>
						<li>input and output devices based on traditional desktop computers</li>
					</ul>
					<li>Limited rendering model (<a href="http://www.w3.org/TR/css3-box/">HTML/CSS box model</a>)</li>
					<ul>
						<li><a href="http://www.w3.org/TR/CSS2/visuren.html">CSS2 floats, absolute positioning, and z-index</a> add sophistication</li>
						<li><a href="http://www.w3.org/TR/css3-layout">CSS3 Advanced Layout</a> adds more flexible/advanced layouts</li>
						<li><a href="http://www.w3.org/TR/2dcontext/">HTML5 Canvas 2D</a> adds vector graphics to HTML's layout</li>
					</ul>
					<li>Dependency on HTTP interactions</li>
					<ul>
						<li><link href="localstorage"/> and <link href="ajax">Ajax</link> can make HTTP a runtime decision</li>
					</ul>
					<li>Always invoked in <em>Software as a Service (SaaS)</em> mode</li>
					<ul>
						<li>software is not installed but served remotely</li>
						<li>client-side code is only supported as part of general HTTP caching</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>iPhone Apps</title>
				<ul>
					<li>iPhone released in 06/2007 with no add-on applications</li>
					<ul>
						<li><em>Safari Mobile</em> as a high-end mobile browser</li>
						<li>support for sophisticated Web applications and offline mode</li>
					</ul>
					<li>Developers were disappointed by the lack of device access</li>
					<li>10/2007 early announcement of native SDK, officially announced in 03/2008</li>
					<li>iPhone OS 2.x released 07/2008 supported native applications</li>
					<ul>
						<li>SDK released in 03/2008 based on Apple's <a href="http://developer.apple.com/technologies/iphone/cocoa-touch.html">Cocoa Touch</a> framework</li>
						<li>applications can only be distributed through the <em>AppStore</em></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="appcache">
			<title>Caching Application Code</title>
			<slide>
				<title>Going Offline/Online</title>
				<ul>
					<li>Switching offline/online is controlled by the user agent</li>
					<ul>
						<li>it can be controlled by the user (explicit <q>work offline</q> command)</li>
						<li>it can be controlled automatically (monitoring connectivity)</li>
						<li>ideally, the device should have a status of <q>online/offline</q></li>
					</ul>
					<li>Mobile applications can go offline at any point in time</li>
					<ul>
						<li>ideally, switching between modes should not result in failure</li>
						<li>applications doing more than a <http>GET</http> are more challenging to design</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP Cache vs. AppCache</title>
				<ul>
					<li>HTTP caches are part of (almost) all user agents</li>
					<ul>
						<li>they cache HTTP responses based on HTTP methods and metadata</li>
						<li>they are supposed to be transparent and should not change behavior</li>
					</ul>
					<li>Caching application code can be <q>just optimization</q></li>
					<ul>
						<li>all code/resources for Web-based applications is delivered as HTTP responses</li>
						<li>if everything is reliably cached, offline applications are possible</li>
					</ul>
					<li>Caching application code needs some explicit <q>hints</q></li>
					<ul>
						<li>all required resources need to be available</li>
						<li><q>updating</q> the cached application is only possible in online mode</li>
						<li>in some cases, application caching should be <q>aggressive</q></li>
						<li>user agents should have a general control for removing origin-specific data</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>What Applications Need</title>
				<ul>
					<li>Web Pages (HTML)</li>
					<li>Style Sheets (CSS)</li>
					<li>Scripting Code (JavaScript)</li>
					<li>Images (GIF, PNG, JPG)</li>
					<li>Additional resources</li>
					<ul>
						<li>in many cases this may be dynamically changing data</li>
						<li>this might also include resource access other that <http>GET</http></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Media Resources</title>
				<img src="resources-media.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
		</part>
		<part>
			<title>Detecting State Changes</title>
			<slide>
				<title>Going Offline/Online</title>
				<ul>
					<li>Applications should be able to check connectivity</li>
					<ul>
						<li>do not even try HTTP if there is no connectivity</li>
						<li>avoid network access or start using <link href="localstorage"/></li>
					</ul>
					<li>HTML/DOM has <em>attributes</em> and <em>events</em></li>
				</ul>
				<pre href="http://www.w3.org/TR/html5/browsers.html#window">interface Window {
// the user agent
	readonly attribute Navigator navigator; 
	readonly attribute ApplicationCache applicationCache;
// ....
	attribute Function onoffline;
	attribute Function ononline;
// .... };</pre>
				<pre href="http://www.w3.org/TR/html5/webappapis.html#navigator">interface Navigator {
  // objects implementing this interface also implement the interfaces given below };
Navigator implements NavigatorID;
Navigator implements NavigatorOnLine;
Navigator implements NavigatorAbilities;

[Supplemental, NoInterfaceObject]
interface NavigatorOnLine {
	readonly attribute boolean onLine; };</pre>
			</slide>
			<slide>
				<title>Minimal Online/Offline Demo</title>
				<listing src="online-offline-demo.html"/>
			</slide>
		</part>
		<part>
			<title>Caching Application Data</title>
			<slide>
				<title>Going Offline/Online</title>
				<ul>
					<li>How does a browser know whether it is online or offline?</li>
					<ul>
						<li>UI controls may allow the user to <q>go offline/online</q></li>
						<li>network monitoring allows the browser to understand the status</li>
						<li>OS events could be used to alert the browser of state changes</li>
					</ul>
					<li>Being online should cause a browser to cache all data</li>
					<ul>
						<li>the application cache could be a special part of the regular cache</li>
						<li>application caching has to be done before connectivity is lost</li>
					</ul>
					<li>Many applications have an infinite/updated stream of data</li>
					<ul>
						<li>some resources may be static (code, layout, <q>old data</q>)</li>
						<li>some resources are dynamic (<link href="rest">REST</link> allows infinite exploration)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Media Resources</title>
				<img src="resources-ajax.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>Minimal Online/Offline Demo</title>
				<ul>
					<li>HTML5 code linking to the <em>cache manifest</em></li>
				</ul>
				<listing src="online-offline-demo.html" line="1-5"/>
				<ul>
					<li><em>Cache manifest</em> listing all files that must be cached</li>
				</ul>
				<listing src="manifest.appcache"/>
				<ul>
					<li><em>Cache manifest</em> must be served as <mime>text/cache-manifest</mime></li>
				</ul>
				<listing src=".htaccess"/>
			</slide>
			<slide>
				<title>Manifest Sections</title>
				<ul>
					<li>Manifests have three different sections</li>
					<ul>
						<li><code>CACHE</code>: can and should be cached by the browser</li>
						<li><code>NETWORK</code>: requires a live connection</li>
						<li><code>FALLBACK</code>: pair-wise lists of fallback alternatives</li>
					</ul>
				</ul>
				<pre href="http://www.w3.org/TR/html5/offline.html#manifests">CACHE MANIFEST
CACHE:
style/default.css
images/sound-icon.png
images/background.png
NETWORK:
comm.cgi
FALLBACK:
/ /offline.html
</pre>
			</slide>
			<slide>
				<title>Updating Cached Applications</title>
				<ul>
					<li>Must be done by the client every time the application is loaded</li>
					<ul>
						<li>can be invoked and controlled by the client application itself</li>
					</ul>
				</ul>
				<pre href="http://www.w3.org/TR/html5/offline.html#application-cache-api">interface ApplicationCache {
// update status
	const unsigned short UNCACHED = 0;
	const unsigned short IDLE = 1;
	const unsigned short CHECKING = 2;
	const unsigned short DOWNLOADING = 3;
	const unsigned short UPDATEREADY = 4;
	const unsigned short OBSOLETE = 5;
	readonly attribute unsigned short status;
// updates
	void update();
	void swapCache();
// events
	attribute Function onchecking;
	attribute Function onerror;
	attribute Function onnoupdate;
	attribute Function ondownloading;
	attribute Function onprogress;
	attribute Function onupdateready;
	attribute Function oncached;
	attribute Function onobsolete;
};
</pre>
			</slide>
		</part>
	</presentation>
	<presentation id="camera">
		<title short="Camera">Camera Access</title>
		<date>2010-03-17</date>
		<toc class="resources"><a href="http://www.w3.org/2009/dap/" title="W3C Device APIs and Policy Working Group">W3C DAP</a></toc>
		 <toc class="abstract">As a case study, we look at the (seemingly) simple task of <em>how to add camera access to a mobile application</em>. It turns out that this cannot be easily done in any Web-based application that is supposed to be working across a large range of devices. However, as an exercise of surveying the mobile ecosystem (and thus highlighting the difficulties of navigating this constantly changing landscape), in this lecture we look at the available options, and at the trade-offs involved with every of those options.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Camera Access</title>
			<slide>
				<title>Sharing Experiences</title>
				<img src="eye-fi.jpg" style="float : right ; margin : 0 1em 2em 2em ; width : 20% " href="http://www.eye.fi/" title="Memory card with integrated Wi-Fi"/>
				<ul>
					<li>Cameras and phones are still in the process of merging</li>
					<ul>
						<li>phone cameras are becoming increasingly sophisticated</li>
						<li>dedicated cameras are still making substantial progress</li>
						<li>a relevant share of cameras are also phones</li>
					</ul>
					<li>Cellphone cameras have a problem with sharing pictures</li>
					<ul>
						<li>backup/synchronization allows handling similar to dedicated cameras</li>
						<li><em href="http://en.wikipedia.org/wiki/Multimedia_Messaging_Service" title="Multimedia Messaging Service">MMS</em> extended <em href="http://en.wikipedia.org/wiki/SMS" title="Short Message Service">SMS</em> (and added outlandish pricing models)</li>
						<li>email clients allow some sharing (not tied into the Web)</li>
						<li>mostly native apps for easy taking/uploading/sharing</li>
					</ul>
					<li>There are other ways of how sharing can be implemented</li>
					<ul>
						<li>cameras can upload pictures without user intervention</li>
						<li>Web-based services then can implement sharing strategies</li>
						<li><a href="http://www.eye.fi/">Eye-Fi</a> allows automatic push from cameras</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Mobile Cameras</title>
				<img src="bill-phones.jpg" style="height : 65% ; margin : 4% ; " href="http://www.flickr.com/photos/unsureshot/271812749/"/>
			</slide>
			<slide>
				<title>Flickr Camera Models</title>
					<img src="flickr-cameras.png" style="width : 90% ; margin : 2em ; " href="http://www.flickr.com/cameras/"/>
			</slide>
			<slide>
				<title>Decoding Encoded Reality</title>
				<img src="qr.png" style="float : right ; margin : 0 1em 2em 2em ; width : 20% " href="http://chart.apis.google.com/chart?cht=qr&amp;chs=500x500&amp;chl=http://dret.net/lectures/mobapp-spring10/" title="QR Code for http://dret.net/lectures/mobapp-spring10/"/>
				<ul>
					<li>QR codes can provide entry points</li>
					<ul>
						<li>they can be used as a springboard <em>into the Web</em></li>
						<li>they can be used as <em>data input</em> in any application</li>
					</ul>
					<li>Many <q>closed</q> application scenarios rely on QR tagging</li>
					<ul>
						<li>users can be expected to have appropriate devices and behavior</li>
						<li>there can be assumptions about the encoded data</li>
					</ul>
					<li>Web technologies have not yet embraced QR codes</li>
					<ul>
						<li>is there any browser that supports QR for addresses or data input?</li>
						<li>things might with more and more <a href="http://www.flickr.com/groups/qrcodes/pool/">QR Codes in the wild</a></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Cameras and Privacy</title>
				<ul>
					<li>Camera access is highly sensitive to privacy considerations</li>
					<ul>
						<li>Web applications have to go through some access control</li>
						<li>access management is both important and complicated</li>
					</ul>
					<li><q>Applications</q> may be more trustworthy than <q>the Web</q></li>
					<ul>
						<li>not technically true but applications simply are more heavy-weight</li>
						<li>the browser as a sandbox traditionally has protected users</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Mobile Devices and Privacy</title>
				<ul>
					<li>Mobile devices introduce a new dimension of privacy problems</li>
					<ul>
						<li>more <q>trusted</q> than computers (but more trustworthy?)</li>
						<li>part of many more activities and situations</li>
						<li>an increasingly sophisticated array of sensors</li>
					</ul>
					<li><a href="http://www.w3.org/2009/dap/">W3C Device APIs and Policy Working Group</a> has a long-term focus</li>
					<ul>
						<li>targeting devices specifically from the mobile ecosystem</li>
						<li>some aspects excluded from scope (widgets, geolocation, notification)</li>
						<li>hopefully some common framework for device access APIs and privacy issues</li>
					</ul>
					<li>Balancing features/power and privacy is a delicate issue</li>
					<ul>
						<li>adding more control elements to browsers does not solve the problem</li>
						<li>should the Web remain disconnected from privacy-sensitive data?</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Mobile Platform Landscape Overview</title>
				<img src="mobile-platforms.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
		</part>
		<part>
			<title>Web Technologies</title>
			<part>
				<title>HTML Forms</title>
				<slide>
					<title>Generic File Upload</title>
					<ul>
						<li>Forms allow general file uploads</li>
						<ul>
							<li>most form fields are for direct data entry</li>
							<li>one special form field activates the OS file selection dialog</li>
							<li>this is the only access to a client's general data storage</li>
						</ul>
						<li>Form file uploads are using the platform-specific file selection</li>
						<ul>
							<li>files are selected based on the client's conventions</li>
							<li>files are sent as multipart messages with <http>POST</http> requests</li>
						</ul>
						<li>Form uploads essentially use the same mechanism as email</li>
						<ul>
							<li>HTML forms can upload any number of files</li>
							<li>servers are expected to unpack and process them</li>
							<li>processing options are file storage or input to further processing</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>HTML Form Example</title>
					<listing src="file-form.html"/>
				</slide>
				<slide>
					<title>Form Uploader Example</title>
					<listing src="file-uploader.php"/>
				</slide>
				<slide>
					<title>HTML Forms Limitations</title>
					<ul>
						<li>Not supported on all mobile devices</li>
						<ul>
							<li>iPhone Mobile Safari always disables file upload controls in forms</li>
						</ul>
						<li>Inconvenient for multiple uploads (frequent use case for images)</li>
						<ul>
							<li>only one file per form control can be selected</li>
							<li>additional form controls can be created via scripting</li>
							<li>one form control per file in many cases is not convenient</li>
						</ul>
						<li>Workarounds are used in different forms</li>
						<ul>
							<li>Flickr uses Flash upload (allows selection of multiple files)</li>
							<li>Facebook uses Java Applet (allows previews and preprocessing)</li>
							<li>email uploads circumvent forms altogether (<q>magic</q> email address)</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>very well-established Web technology</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>very indirect (take picture, store it, upload it)</li>
							<li>inconvenient for multiple uploads</li>
							<li>not supported on some <q>embedded</q> devices (e.g., iPhone)</li>
							<li>no support for more advanced interactions (<q>live capture</q>)</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>MMS</title>
				<slide>
					<title>Multimedia Phone Services</title>
					<ul>
						<li><em href="http://en.wikipedia.org/wiki/Multimedia_Messaging_Service">Multimedia Messaging Service (MMS)</em> extended <em href="http://en.wikipedia.org/wiki/SMS" title="Short Message Service">SMS</em></li>
						<ul>
							<li>adding the ability to send <q>multipart messages</q></li>
						</ul>
						<li>MMS composition on phones can add <q>attachments</q></li>
						<li>Web-based applications could invoke MMS composition</li>
						<ul>
							<li>there is no standard scheme for identifying <q>MMS URIs</q></li>
							<li>phones support for <q>MMS URIs</q> would take a while</li>
							<li>the image is transported via an out-of-band mechanism</li>
						</ul>
						<li>MMS implementation uses HTTP but is inaccessible to developers</li>
						<ul>
							<li>MMS handsets retrieve receive MMS messages via HTTP</li>
							<li>MMS is essentially expensive multipart email</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>can use a phone's existing multimedia support</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>no URI scheme for MMS addressing</li>
							<li>no phone support for composing MMS messages from Web content</li>
							<li>out-of-band messaging</li>
							<li>may incur substantial costs</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>HTML5</title>
				<slide>
					<title>Camera Access on the Web</title>
					<ul>
						<li><q>Hardware access</q> is traditionally limited on the Web</li>
						<ul>
							<li>screen-based output is the only output medium</li>
							<li>input is limited to keyboard and mouse</li>
						</ul>
						<li><q>Multimedia</q> applications often bypass standard Web technologies</li>
						<ul>
							<li>audio support is simple in Flash and other plugins</li>
						</ul>
						<li>HTML5 APIs start targeting more advanced access to data/devices</li>
						<ul>
							<li>camera access is identified but not yet included</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>none</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>cameras not yet part of official HTML5 plans</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>Platform-Specific Runtimes</title>
			<part>
				<title>Flash</title>
				<slide>
					<title>The 900lb Gorilla</title>
					<ul>
						<li>Used to be taken for granted in the pre-mobile days</li>
						<ul>
							<li>iPhone/iPad seriously challenge the ubiquity of Flash support</li>
						</ul>
						<li>Support limited based on underlying OS</li>
						<ul>
							<li>Flash support for iPhone/iPad is unlikely to happen</li>
							<li>Flash support for Android is planned (probably only 2.1 and later)</li>
							<li>Flash support for WebOS and Windows Mobile can be expected</li>
						</ul>
						<li>Camera access from Flash is trivial</li>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>widely deployed on the computer Web</li>
							<li>may see some adoption on the mobile Web</li>
							<li>some developers have experience with Flash</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>not part of the Web (develop Flash code instead of Web code)</li>
							<li>only works with a (potentially small) subset of mobile devices</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>BONDI</title>
				<slide>
					<title>Pre-HTML5 Advanced Web APIs</title>
					<img src="bondi.png" style="float : right ; margin : 0 1em 2em 2em ; width : 20% " href="http://bondi.omtp.org/"/>
					<ul>
						<li>Platform vendors attempting to bridge the gap</li>
						<ul>
							<li>phones are providing increasingly sophisticated features</li>
							<li>browsers become more powerful but provide little platform support</li>
						</ul>
						<li>BONDI has been established as a vendor initiative</li>
						<ul>
							<li>phone manufacturers, network operators, service providers</li>
							<li>first reference implementation based on Windows Mobile 6</li>
							<li><a href="http://bondi.omtp.org/whatisbondi/Lists/NewsList/DispForm.aspx?ID=9">BONDI 1.1 approved in early 2010</a> and should be available soon</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>some support across vendor platforms</li>
							<li>comprehensive platform for better platform access</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>future is uncertain (alignment with HTML5/DAP is pending)</li>
							<li>support seems to be very limited as of today</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>WRT</title>
				<slide>
					<title><q>Nokia's BONDI</q></title>
					<ul>
						<li>Nokia-specific API for platform services</li>
						<ul>
							<li>available on Symbian devices only</li>
							<li>support on Maemo/MeeGo may or may not happen</li>
						</ul>
						<li>APIs and widget development environment</li>
						<ul>
							<li>APIs for providing access to platform-specific functions</li>
							<li>widget support for development and deployment of applications</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>good market coverage (Symbian has a large market share)</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>only supported by a subset of installed Symbian versions</li>
							<li>only supported by Nokia devices (not even all Nokia smartphones)</li>
							<li>unclear alignment with BONDI and HTML5</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>PhoneGap/QuickConnect</title>
				<slide>
					<title>Bridging the Gap</title>
					<ul>
						<li>Bundling access to <q>missing functionality</q></li>
						<li>Based on WebKit and adding access to device APIs</li>
						<li>Web code and PhoneGap/QuickConnect runtime are bundled as a native application</li>
						<li>Application development requires native SDK access</li>
						<ul>
							<li>setup and configuration can be complicated</li>
							<li>native SDKs for all targeted platforms must be available</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Pro/Con</title>
					<ul>
						<li>Advantages:</li>
						<ul>
							<li>good mix of Web development and API support</li>
							<li>requires no framework installation on the device</li>
							<li>porting applications just requires rebuilding it</li>
						</ul>
						<li>Disadvantages:</li>
						<ul>
							<li>requires installation on the device (packaged runtime)</li>
							<li>requires approval in some application stores (depending on platform)</li>
							<li>application updates can be tricky (depending on design)</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>Native Applications</title>
			<slide>
				<title>Sophisticated and Expensive</title>
				<ul>
					<li>Provides full access to the underlying API</li>
					<ul>
						<li>device APIs can be more powerful/flexible than Web-level abstractions</li>
						<li>QR recognition is more convenient with <a href="http://www.tuaw.com/2009/12/15/apple-relents-and-is-now-allowing-uigetscreenimage-for-app-st/">constant capture</a></li>
					</ul>
					<li>Development is complex and very platform-specific</li>
					<ul>
						<li>different programming languages</li>
						<li>different framework conventions</li>
						<li>different APIs on each platform</li>
					</ul>
					<li>Deploying can be difficult</li>
					<ul>
						<li>platform vendors may have strict guidelines for application deployment</li>
						<li>installing applications may be a complicated process</li>
						<li>users have to find/install/setup the application</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Pro/Con</title>
				<ul>
					<li>Advantages:</li>
					<ul>
						<li>no limitations other than actual device limitations</li>
						<li>some platforms have managed application purchasing services</li>
					</ul>
					<li>Disadvantages:</li>
					<ul>
						<li>complex development (expensive and fewer available developers)</li>
						<li>very little reuse across various platforms</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="project-setup">
		<title short="Project Setup">Final Project Setup</title>
		<date>2010-03-19</date>
		<toc class="resources"><a href="http://www.scvngr.com/">SCVNGR</a></toc>
		 <toc class="abstract">Discussion about the scope and possible ideas for the final project. More details about the exact requirements and constraints for final projects will be made available at a later date.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Scope</title>
			<slide>
				<title>Client Side Development</title>
				<ul>
					<li>Mobile applications need specifically <q>mobile-aware</q> designs</li>
					<ul>
						<li>the user context often is very different</li>
						<li>mobile devices provide a very diverse landscape</li>
					</ul>
					<li>Having well-defined starting points is essential</li>
					<ul>
						<li>what are the situations in which users are using the application?</li>
						<li>what kind of interactions/devices is the application supporting?</li>
						<li>what are contexts/devices specifically excluded from the design?</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Side Development</title>
				<ul>
					<li>Many mobile applications need some service</li>
					<ul>
						<li>social applications by definition must have a place to connect</li>
						<li>personal applications might need backup or synchronization</li>
						<li>mobile interfaces may be limited in functionality</li>
					</ul>
					<li><q>Tight Coupling</q> vs. <q>Loose Coupling</q></li>
					<ul>
						<li>mobile applications should be able to work with slow networks</li>
						<li>mobile applications should be able to handle offline scenarios</li>
						<li>mobility across devices (e.g., mobile to laptop) is an interesting topic</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Client/Server Interactions</title>
				<ul>
					<li>How to design mobile scenarios with client/server interactions</li>
					<ul>
						<li>REST as the underlying principle is a good starting point</li>
						<li>how to specifically design and implement RESTful services?</li>
					</ul>
					<li>Understanding the impact of connectivity and speed</li>
					<ul>
						<li>designing the right granularity can make a big difference</li>
						<li>designing smart caching/offline can make a big difference</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Requirements</title>
			<slide>
				<title>Design and Implementation</title>
				<ul>
					<li>Applications are as good as their weakest part</li>
					<ul>
						<li>great design and poor implementation does not work very well</li>
						<li>poor design and great implementation will not attract many users</li>
					</ul>
					<li>Very different approaches between corporate IT and open IT</li>
					<ul>
						<li>users of corporate IT solutions often have no alternatives</li>
						<li>open IT is a free market where users can walk away any time</li>
					</ul>
					<li><q>Bridging the front-end and the back-end</q></li>
					<ul>
						<li>front-end can be challenging because of heterogeneity</li>
						<li>how well does the back-end support very different front-ends?</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Design</title>
				<ul>
					<li>Users, personas, use cases, scenarios</li>
					<ul>
						<li>based on current uses and devices</li>
						<li>looking forward to slightly futuristic uses and devices</li>
					</ul>
					<li><q>Interaction Design</q> of users (i.e., user agents) and services</li>
					<ul>
						<li>RESTful design is all about identifying resource interactions</li>
						<li>how do users navigate the space of available resources?</li>
						<li>identifying resources <em>and their connections</em> is a key issue</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Implementation</title>
				<ul>
					<li>Design the implementation yourself (starting from the <link href="landscape"/>)</li>
					<ul>
						<li>explore the design options and critically review the trade-offs</li>
						<li>focus on building a client (platform issues)</li>
						<li>focus on building a server (empowering certain classes of platforms)</li>
					</ul>
					<li>Use an existing implementation framework</li>
					<ul>
						<li>pre-built platforms such as <a href="http://www.scvngr.com/">SCVNGR</a></li>
						<li>explore and critically review the trade-offs of the selected platform</li>
						<li>can the platform be extended/augmented to better fit your needs?</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Options</title>
			<slide>
				<title>Project Focus</title>
				<ul>
					<li>UI/UX design with an eye on implementation issues</li>
					<ul>
						<li>how do technical issues inform the UI/UX side of the project?</li>
					</ul>
					<li>Implementation design with an eye on UI/UX issues</li>
					<ul>
						<li>how do UI/UX requirements inform technical design decisions?</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="project-proposal">
		<title short="Project Proposal">Final Project Proposal</title>
		<date>2010-03-29</date>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Project Proposal">A6: Proposal</a> (assigned: 3/29; due: 4/5)</toc>
		<toc class="abstract">The final project is supposed to cover a mobile application all the way from the use cases to implementation issues. In this lecture, we look at the expected format of the project proposal and the different issues that need to be addressed in the proposal. Most importantly, the proposal has to contain a section on <em>application design</em> as well as a section on <em>application implementation</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Project Outline</title>
			<slide>
				<title>Scope</title>
				<ul>
					<li>Focus on something achievable</li>
					<ul>
						<li>final projects will not lead to complete applications</li>
						<li>we do expect some level of detail in design/implementation</li>
						<li>deciding what to do specifically can be hard</li>
					</ul>
					<li>Try to not re-invent the wheel</li>
					<ul>
						<li>hard to do because there are many existing applications and services</li>
						<li>if there is <q>competition</q>, describe what is different</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Use Cases</title>
				<ul>
					<li>Describe scenarios in which your application will be useful</li>
					<ul>
						<li>describe how it is useful for the end-user (black box)</li>
						<li>describe what the application/service needs to do (implementation)</li>
						<li>describe other necessary components (community or services)</li>
					</ul>
					<li><q>Non-Use-Cases</q> can be helpful as well</li>
					<ul>
						<li>describe scenarios that you are not targeting</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Project Design</title>
			<slide>
				<title>User Contributions</title>
				<ul>
					<li>Activities where the application is useful</li>
					<ul>
						<li>describing typical scenarios/situations</li>
						<li>how might the application be useful in that specific case?</li>
						<li>how does this compare to a situation without having the application?</li>
					</ul>
					<li>Several inputs are required from the user</li>
					<ul>
						<li>direct inputs in the form of <q>data entry</q></li>
						<li>indirect inputs because of user context (e.g., time or location)</li>
						<li>3rd party triggers (user arrives at a location)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Application Contributions</title>
				<ul>
					<li>What is the application doing as a black box?</li>
					<ul>
						<li>what are the inputs/outputs of the black box?</li>
						<li>list all required inputs to get to the proposed output</li>
						<li>do not assume some magic entity solving the hard part</li>
					</ul>
					<li>Briefly think about scalability issues</li>
					<ul>
						<li>would it still work with thousands/millions of users</li>
						<li>does scale add value or cost or both?</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Community Contributions</title>
				<ul>
					<li>Is there some form of community?</li>
					<ul>
						<li>if so, then the data model must include this as well</li>
					</ul>
					<li>What is the community model?</li>
					<ul>
						<li>users are on their own</li>
						<li>reusing one of the existing networks (Facebook, Twitter, …)</li>
						<li>building a new network</li>
					</ul>
					<li>How does the community provide <q>input</q>?</li>
				</ul>
			</slide>
			<slide>
				<title>User Interface Design</title>
				<ul>
					<li>How is the user interface going to look like?</li>
					<ul>
						<li>different implementation choices result in different UI options</li>
					</ul>
					<li>UI design should start with simple sketches and outlines</li>
					<ul>
						<li>design-focused proposals will need to develop specific UI designs</li>
						<li>implementation-focused proposals might focus on functionality instead</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Project Implementation</title>
			<slide>
				<title>Layer Cake</title>
				<ul>
					<li>Technical descriptions should be layered</li>
					<ul>
						<li><q>Separation of Concerns</q> helps to better describe scenarios</li>
					</ul>
					<li>Data models help a lot to figure out the data structures</li>
					<li>Behavior models help a lot to figure out the processes</li>
					<li>Sophisticated models use many different diagram types</li>
					<ul>
						<li><a href="http://en.wikipedia.org/wiki/Unified_Modeling_Language" title="Unified Modeling Language">UML</a> 2.2 has <a href="http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams_overview">14 diagram types</a> to model systems</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Client Side</title>
				<ul>
					<li>Implementation platform</li>
					<ul>
						<li>talk about the <link href="landscape"/> and where you fit in</li>
					</ul>
					<li>What is the client side implementation using?</li>
					<ul>
						<li>list all client side requirements</li>
					</ul>
					<li>What other implementation options exist?</li>
					<ul>
						<li>explain why some implementations might not work</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Side</title>
				<ul>
					<li>Which services are provided by a server implementation?</li>
					<li>What are the resources applications interact with?</li>
					<ul>
						<li>figure out the <em>resource types</em></li>
						<li>figure out all relationships between these types</li>
						<li>figure out all interactions supported for each of the types</li>
					</ul>
					<li>Looking at Flickr is a good starting point</li>
					<ul>
						<li><em>images</em> are the first central resource type</li>
						<li><em>users</em> are the second central resource type</li>
						<li><em>sets</em> and <em>collections</em> allow users to organize pictures</li>
						<li><em>groups</em> allow users to share pictures</li>
						<li>important additional details are tags, comments, galleries, …)</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="droid">
		<title short="Droid">Hardware/Platform Opinions</title>
		<date>2010-03-31</date>
		<toc class="abstract">Based on the first experiences with the new devices, today we briefly review some impressions about that device and the platform it provides. This involves listing some observations about likes and dislikes regarding the device/platform in general, as well as some initial ideas how useful that platform will be for the mobile application of the final project.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Creating QR Codes</title>
			<img src="qr-generator.png" style="height : 65% ; margin : 4% ; " href="http://www.mskynet.com/static/maestro"/>
		</slide>
		<slide>
			<title>Reading QR Codes</title>
			<img src="barcode-scanner.jpg" style="height : 65% ; margin : 4% ; " href="http://www.androidzoom.com/android_applications/shopping/barcode-scanner_clh.html"/>
		</slide>
		<part>
			<title>Good Things</title>
			<slide>
				<title>Geolocation/Mapping</title>
				<ul>
					<li>Most functionality from the Web-based map</li>
					<ul>
						<li><q>terrain view</q> available as a <q>layer</q></li>
						<li>all of <q>My Maps</q> available as individual layers</li>
					</ul>
					<li>There also is a <a href="http://code.google.com/apis/maps/documentation/mapsdata/developers_guide_protocol.html">My Maps API</a></li>
					<ul>
						<li>create maps programmatically for mobile services</li>
						<li>add them to a user's maps to make the available on Android</li>
						<li><em>Maps</em> application would need some interface changes</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>My Maps</title>
				<img src="ucb-campus.png" style="height : 65% ; margin : 4% ; " href="http://maps.google.com/maps/ms?ie=UTF&amp;msa=0&amp;msid=116962062413210327627.00043de7109aff5329452"/>
			</slide>
			<slide>
				<title>My Maps QR</title>
				<img src="ucb-campus-qr.png" style="height : 65% ; margin : 4% ; " href="http://maps.google.com/maps/ms?ie=UTF&amp;msa=0&amp;msid=116962062413210327627.00043de7109aff5329452"/>
			</slide>
			<slide>
				<title>Camera Quality</title>
				<ul>
					<li>Decent resolution and autofocus for acceptable quality</li>
					<ul>
						<li>additional settings for advanced controls</li>
					</ul>
					<li>LED flash for reasonably lit indoor scenes</li>
					<ul>
						<li>it even doubles as a <a href="http://www.google.com/search?q=droidlight">flashlight</a></li>
					</ul>
					<li>Handling images seems to suffer from some coordination problems</li>
					<ul>
						<li>rotation does not seem to be handled by all applications</li>
						<li>the Facebook application uploads stamp-sized versions of pictures</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Open Platform</title>
				<ul>
					<li>No mandatory review with opaque decision procedures</li>
					<li>Availability on various devices with different characteristics</li>
					<ul>
						<li>application development becomes harder (fragmentation)</li>
						<li>platform development may split into various code lines</li>
					</ul>
					<li>How much openness can phones afford?</li>
					<ul>
						<li>if it works well without tinkering, probably a lot</li>
						<li>if it remains stable with tinkering, probably a lot</li>
						<li>if it compromises the phone's utility, not too much</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Bad Things</title>
			<slide>
				<title>Email</title>
				<ul>
					<li>There is no general-purpose Email client</li>
					<ul>
						<li>good support for Gmail users (Gmail application)</li>
						<li>almost no support for non-Gmail users (Email application)</li>
					</ul>
					<li>Good integration with Google services is an advantage</li>
					<ul>
						<li>Email, Calendar, Contacts, Maps, …</li>
					</ul>
					<li>Lack of support for standard services is disappointing</li>
				</ul>
			</slide>
			<slide>
				<title>Quality Control</title>
				<ul>
					<li>Less <q>polished experience</q> than the iPhone</li>
					<ul>
						<li>less sophistication in UI design and refinement</li>
						<li>fewer guidelines for developers</li>
						<li>no curated market with quality control for applications</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Web Application Support</title>
				<ul>
					<li>Adding bookmarks is more complicated than it should be</li>
					<ol>
						<li>bookmark the page you want to add to a home screen</li>
						<li>go to the home screen you want to add the link to</li>
						<li>long-press in an empty space to bring up the <q>Add to Home Screen</q> menu</li>
						<li>select <q>Shortcuts</q></li>
						<li>select <q>Bookmark</q></li>
						<li>choose the bookmark (it will get a generic/favicon combo)</li>
					</ol>
					<li>No support for Web-based widgets</li>
					<ul>
						<li>widgets are <a href="http://developer.android.com/guide/topics/appwidgets/index.html">native Android applications</a></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Final Project Considerations</title>
			<slide>
				<title>Observations of Daily Living (ODL)</title>
				<ul>
					<li><link href="localstorage"/> supported in the browser</li>
					<li><link href="offline"/> supported in the browser</li>
					<li>WebKit-based browsers (supports all major Web standards)</li>
					<li>Starting a Web-based version as a prototype and demo application</li>
					<ul>
						<li>more advanced features might require switching to PhoneGap/native</li>
						<li>developing a Web-based prototype will be a good starting point</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="project-example">
		<title short="Project Example">Final Project Design and Implementation</title>
		<date>2010-04-02</date>
		<toc class="abstract">As an example of a final project, in this lecture we discuss the scenario of <em>Observations of Daily Living (ODL)</em> and how this information can be created, managed, and exchanged with mobile applications. While the back-end of the particular scenario is connected to a lot of highly complex systems and interfaces managing health-related information, the front-end and the user-centered management can be regarded as an application that should be more or less self-contained.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>QR Codes in the Browser</title>
			<img src="firefox-mobile-barcoder.png" style="height : 65% ; margin : 4% ; " href="https://addons.mozilla.org/en-US/firefox/addon/2780" title="Generating QR Codes in Firefox with Mobile Barcoder"/>
		</slide>
		<part>
			<title>Outline</title>
			<slide>
				<title>Capturing Health-Related Observations</title>
				<ul>
					<li>Information exchange between medical professionals</li>
					<ul>
						<li>existing standards for information exchange between professionals</li>
						<li>existing services for storing and managing health records</li>
					</ul>
					<li>How to get health-related information from patients</li>
					<ul>
						<li>current scenarios look mostly at information sharing between professionals</li>
						<li>patient data (observations and notes) are not part of the current landscape</li>
					</ul>
					<li>Developing a model and an application for patient-generated data</li>
					<ul>
						<li><em>Observations of Daily Living (ODL)</em> can be very useful for doctors</li>
						<li>the models around creation, sharing, delegation, and exchange have to be flexible</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Personal Health Information</title>
				<img src="circle-of-life.jpg" style="height : 65% ; margin : 4% ; " href="http://www.continuaalliance.org/about-the-alliance.html"/>
			</slide>
			<slide>
				<title>Monitoring Body Weight</title>
				<img src="withings.png" style="height : 65% ; margin : 4% ; " href="http://www.withings.com/en/bodyscale/monitoring"/>
			</slide>
		</part>
		<part>
			<title>Design</title>
			<slide>
				<title>Scenarios</title>
				<ul>
					<li>Activities where the application is useful</li>
					<ul>
						<li>elder activities (<a href="http://www.projecthealthdesign.org/projects/current_projects/cmu">CMU Project</a>)</li>
						<li>asthma and depression or anxiety (<a href="http://www.projecthealthdesign.org/projects/current_projects/breatheasy">BreathEasy</a>)</li>
						<li>youth with obesity and depression (<a href="http://www.projecthealthdesign.org/projects/current_projects/iN_Touch">iN Touch</a>)</li>
						<li>tracking chronic disease (<a href="http://www.projecthealthdesign.org/projects/current_projects/crohnology">Crohnology.MD</a>)</li>
						<li>monitoring low birth weight infants (<a href="http://www.projecthealthdesign.org/projects/current_projects/fitbaby">FitBaby</a>)</li>
					</ul>
					<li>Requirements derived from those use cases</li>
					<ul>
						<li>various activities require different data to be captured</li>
						<li>data should be captured in a structured form for easier use/analysis</li>
						<li>data input must be simple and easy</li>
						<li>augmenting observations should be possible (using <q>connected devices</q>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Acquiring User Input</title>
				<ul>
					<li>Different scenarios need different data input</li>
					<ul>
						<li>some template mechanism is required for acquiring structured data</li>
						<li>templates could be used to generate form-based data entry</li>
						<li>part of the templating mechanism should be <q>external data</q></li>
					</ul>
					<li>Pulling in external data can be done in various ways</li>
					<ul>
						<li>custom-built based on individual mechanisms per data provider</li>
						<li>based on generic Web standards such as feeds (and some extraction mechanism)</li>
						<li>based on specific standards for sharing health data (e.g., <a href="http://www.continuaalliance.org/">Continua</a>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Delegating User Input</title>
				<ul>
					<li>ODLs may be entered by caretakers or parents</li>
					<ul>
						<li>identification/authentication must allow delegation</li>
						<li>ownership and access right model has to be flexible</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>UI Design Issues</title>
				<ul>
					<li>Structured data entry should be encouraged</li>
					<ul>
						<li>use interface elements that make structured data entry easy</li>
						<li>use interfaces that are specific (templates)</li>
						<li>entry helpers (<q>yesterday's ODL</q>) may make data entry easier</li>
					</ul>
					<li>Immediate feedback for providing incentives</li>
					<ul>
						<li>show graphs/trends of values after an ODL has been added</li>
						<li>interface/interaction should be </li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Implementation</title>
			<slide>
				<title>Open and Extensible Model</title>
				<ul>
					<li>ODL reports should be usable for various scenarios</li>
					<li><em>Openness</em> means that application can add specific data</li>
					<ul>
						<li>openness creates the problem of how to understand added data</li>
						<li>various additions can have overlapping meaning</li>
					</ul>
					<li><em>Extensibility</em> means that the model might be extended later</li>
					<ul>
						<li>in the best case, old implementations can deal with new data</li>
						<li>in the usual case, new implementations can deal with old data</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Web-Based for Cross-Platform</title>
				<ul>
					<li>Data entry should be possible across platforms</li>
					<ul>
						<li>it may be more convenient on a regular computer</li>
						<li>mobile data entry is necessary to ensure ODL coverage</li>
					</ul>
					<li>Text and simple data entry can be done Web-based</li>
					<ul>
						<li>some mobile platforms may even support speech-to-text soon</li>
						<li>with templates/types data entry can be made easier</li>
					</ul>
					<li>More advanced forms of data entry are not yet supported</li>
					<ul>
						<li><a href="http://www.w3.org/TR/capture-api/">Capture API</a> just published and not yet implemented</li>
						<li>no ability to connect to Bluetooth-enabled devices</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Resource Types</title>
				<ul>
					<li>Users are needed for identification and authentication</li>
					<li>ODL reports are needed for capturing <q>records</q></li>
					<li>ODL templates should provide some outline for ODL reports</li>
					<li>Services may be used to represent ODL consumers</li>
				</ul>
			</slide>
			<slide>
				<title>Resource Relationships</title>
				<ul>
					<li>Users may have a variety of (possible authorizing) relationships</li>
					<ul>
						<li>family relationships may allow access to ODL records</li>
						<li>professional relationships (e.g., caretakers)</li>
						<li>temporary relationships (delegating data entry for a period of time)</li>
					</ul>
					<li>ODLs are created by a user and for a user</li>
					<li>ODLs are created according to a template</li>
					<ul>
						<li>templates define/guide what is contained in an ODL</li>
						<li>templates can also be used for validation of ODLs</li>
						<li>templates are provided by services and used by users</li>
					</ul>
					<li>ODLs are accessible by a service (which might have modification rights)</li>
					<ul>
						<li>can services delegate access rights?</li>
						<li>can access rights be selective (only parts of the ODL)?</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Resource Interactions</title>
				<ul>
					<li>Users and user relationships required for user management</li>
					<ul>
						<li>creating new users is the <q>sign up</q> process</li>
						<li>modifying relationships permanently (family) or temporarily</li>
					</ul>
					<li>Getting templates as the starting point for creating ODLs</li>
					<ul>
						<li>find the service providing the template and select it</li>
					</ul>
					<li>Creating ODLs based on a template</li>
					<ul>
						<li>only accept the ODL if it validates against the template</li>
						<li>how to deal with existing ODLs when a template changes?</li>
					</ul>
					<li>Access a stream of ODLs as published by users</li>
					<ul>
						<li>services need a way how to get new ODLs (push or pull)</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Customizable <q>Portals</q></title>
			<slide>
				<title>Weather Application</title>
				<table width="95%">
					<tr>
						<td>
							<img style="width : 50% ; margin : 10% ; " src="iphone-weather-list.png"/>
						</td>
						<td>
							<img style="width : 50% ; margin : 10% ; " src="iphone-weather-screen.png"/>
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>Weather.gov Web Pages</title>
				<table width="95%">
					<tr>
						<td>
							<img style="width : 70% ; margin : 10% ; " src="weather-gov-regular.png" href="http://forecast.weather.gov/MapClick.php?CityName=Berkeley&amp;state=CA&amp;site=MTR&amp;textField1=37.8717&amp;textField2=-122.272&amp;e=0" title="Regular Weather Page"/>
						</td>
						<td>
							<img style="width : 70% ; margin : 10% ; " src="weather-gov-mobile.png" href="http://mobile.weather.gov/port_mp_ns.php?CityName=Berkeley&amp;site=MTR&amp;State=CA&amp;warnzone=CAZ508" title="Mobile Weather Page"/>
						</td>
					</tr>
				</table>
			</slide>
		</part>
	</presentation>
	<presentation id="server">
		<title short="Server">Server Configuration</title>
		<date>2010-04-05</date>
		<toc class="assignment"><a href="https://bspace.berkeley.edu/portal/site/1a1c3c3a-b351-41d3-95e7-5f6e48b88fdd/page/d488f9e7-81a3-4053-a9c8-41b5aad88eef" title="Offline and Local Storage">A7: Offline App</a> (assigned: 4/5; due: 4/12)</toc>
		<toc class="resources"><a href="http://httpd.apache.org/docs/" title="Apache HTTP Server Documentation">Apache Documentation</a>&#160;· <a href="http://www.fastcgi.com/">FastCGI</a></toc>
		<toc class="abstract">In all scenarios using Web-based services (in Web-based UIs as well as in native applications accessing Web-based services), it is important to control the way in which the server is using HTTP. Popular examples are setting appropriate media types (making sure resources are handled correctly), setting appropriate expiration dates (making sure resources can be cached), handling redirections (if server setup changes should be managed gracefully) and configuring access control (for non-public resources). While all of this can be handled programmatically, using a Web server and server configuration allows many things to be handled in a declarative way.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Current Events</title>
			<part>
				<title>Android 2.1</title>
				<slide>
					<title>New OS Version</title>
					<img src="droid-android-2-1.jpg" style="height : 65% ; margin : 4% ; " title="Droid Android 2.1 Update"/>
				</slide>
			</part>
			<part>
				<title>iPad Release</title>
				<slide>
					<title>Getting Ready</title>
					<img src="ipad-queue.jpg" style="width : 90% ; margin : 2% ; " href="http://www.dailymail.co.uk/sciencetech/article-1263025/iPad-hype-reaches-fever-pitch-queues-form-outside-Apple-stores.html?ITO=1490" title="iPad Queue"/>
				</slide>
				<slide>
					<title>The One</title>
					<img src="ipad3.jpg" style="height : 65% ; margin : 4% ; " href="http://reviews.cnet.com/8301-31747_7-20001505-243.html" title="iPad"/>
				</slide>
			</part>
		</part>
		<part>
			<title>HTTP and Applications</title>
			<slide>
				<title>REST as Infrastructure</title>
				<ul>
					<li><link href="rest">REST</link> is the architectural style of the Web</li>
					<ul>
						<li>very simple Web servers can be set up by just copying files</li>
						<li>simple Web servers can be set up by tweaking server configuration</li>
						<li>Web applications need some server-side code implementing the logic</li>
						<li>complex/large Web applications may need very specific Web server tuning</li>
					</ul>
					<li><link href="http">HTTP</link> is the RESTful language of the Web</li>
					<ul>
						<li>resources can be manipulated using <http>GET</http>, <http>PUT</http>, <http>POST</http>, and <http>DELETE</http></li>
						<li>header fields allow clients and server to exchange interaction metadata</li>
						<li>HTTP support should be part of a Web programming environment</li>
						<li><link href="ajax">Ajax</link> is the client-side (i.e., browser) implementation of the Web</li>
					</ul>
					<li>Any server <q>speaking HTTP</q> is a Web server</li>
					<ul>
						<li>many sites use existing software products as Web servers</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Web Server Survey</title>
				<img src="server-survey.png" style="height : 65% ; margin : 4% ; " href="http://news.netcraft.com/archives/web_server_survey.html" title="Netcraft Server Survey"/>
			</slide>
			<slide>
				<title>Detecting Server Types</title>
				<img src="server-type.png" style="height : 65% ; margin : 4% ; " href="https://addons.mozilla.org/en-US/firefox/addon/3829" title="Inspecting HTTP Header Fields"/>
			</slide>
		</part>
		<part>
			<title>HTTP Servers</title>
			<slide>
				<title>Standalone or Embedded</title>
				<ul>
					<li><em>Standalone Servers</em> are running as separate processes</li>
					<ul>
						<li>they are usually started when the system is started</li>
						<li>they listen for incoming requests</li>
						<li>serving requests may require reading files and/or other processes</li>
					</ul>
					<li><em>Embedded Servers</em> are part of an application platform</li>
					<ul>
						<li>they are started when the application is started</li>
						<li>they listen to incoming requests</li>
						<li>serving requests means dispatching them to application code</li>
						<li><em href="http://tomcat.apache.org/">Apache Tomcat</em> is an implementation of Java Servlet/JSP</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Control</title>
				<img src="xampp-panel.png" style="height : 65% ; margin : 4% ; "/>
			</slide>
			<slide>
				<title>Process Management</title>
				<ul>
					<li>Standalone servers run in a separate OS process</li>
					<ul>
						<li>Apache allows to control how many processes are running</li>
						<li>tuning processes requires knowledge of the hardware and the OS</li>
					</ul>
					<li>Web servers often need to connect to application servers</li>
					<ul>
						<li>Web servers are the <q>Web front-end</q> of the application</li>
						<li>application servers are the <q>back-end</q> of the application</li>
					</ul>
					<li>Web servers and application servers may be different machines</li>
					<ul>
						<li>simple and small-scale applications run everything on one machine</li>
						<li>complex and large applications have layered server schemes</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Layering</title>
				<ul>
					<li>Web servers are the main component for handling HTTP</li>
					<li>Web caches can be a <q>first line of defense</q> for the servers</li>
					<ul>
						<li><a href="http://www.squid-cache.org/">Squid</a> is a popular open source caching proxy</li>
					</ul>
					<li>Load balancers can be placed in front of caching proxies</li>
					<ul>
						<li>spreads load evenly across any number of proxies</li>
						<li>still a centralized architecture for content delivery over the Web</li>
					</ul>
					<li><a href="http://en.wikipedia.org/wiki/Content_delivery_network">Content Delivery Networks (CDN)</a> support non-centralized delivery</li>
					<ul>
						<li>requests are routed to the <q>best</q> delivery point in the network</li>
						<li>load can be spread and is more localized than in centralized scenarios</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Server Setup</title>
				<img src="squid-example.jpg" style="height : 65% ; margin : 4% ; " href="http://www1.ro.squid-cache.org/mail-archive/squid-users/200808/0107.html"/>
			</slide>
			<slide id="cdn-routing">
				<title>CDN Request Routing</title>
				<img style="width : 90% ; margin : 2% ; " src="cdn-routing.jpg" title="CDN Request Routing" href="http://www.research.ibm.com/journal/sj/431/gayek.html"/>
			</slide>
			<slide>
				<title>CGI and FastCGI</title>
				<ul>
					<li><link href="cgi">CGI</link> connects servers and applications</li>
					<ul>
						<li>a set of conventions for how to package request/response information</li>
						<li>the conventions are based on <em href="http://en.wikipedia.org/wiki/Inter-process_communication">Inter-process Communications (IPC)</em></li>
						<li>IPC only works between processes on the same machine</li>
					</ul>
					<li><a href="http://www.fastcgi.com/">FastCGI</a> extends CGI to be Internet-based</li>
					<ul>
						<li>CGI conventions packaged to be transported via TCP</li>
					</ul>
					<li>FastCGI has two major benefits over CGI</li>
					<ul>
						<li>communications are not limited to processes on the same machine</li>
						<li>application server processes are running continuously</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Integrated Server Handling</title>
				<ul>
					<li>PHP (and other code) can be run as a module or via CGI</li>
					<li>Modules are compiled/configured into the server code</li>
					<li>Modules have advantages and disadvantages</li>
					<ul>
						<li>advantages: faster</li>
						<li>disadvantages: tighter coupling (crashes, code updates)</li>
					</ul>
					<li>CGI executables have advantages and disadvantages</li>
					<ul>
						<li>advantages: more secure (different processes/account)</li>
						<li>disadvantages: less performance (process creation)</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="access">
		<title short="Access">Access Control</title>
		<date>2010-04-07</date>
		<toc class="resources"><a href="http://httpd.apache.org/docs/2.2/howto/auth.html" title="Apache Authentication, Authorization and Access Control">Apache Access Control</a></toc>
		<toc class="abstract">Many resources for mobile applications need to be access controlled. Common reasons for this are security or privacy considerations. There are a number of common methods of how access control can be implemented, and in this lecture we look at some of the fundamental methods (HTTP <em>Basic Authentication</em> and <em>Digest Access Authentication</em> which need to be configured in the server) and the underlying methods for encoding and encrypting data.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Web Server Configuration</title>
			<slide>
				<title>Server Rules</title>
				<ul>
					<li>Web servers are server-side implementations of HTTP</li>
					<li>Running them requires a set of rules</li>
					<ul>
						<li>on which port to listen for incoming requests</li>
						<li>from where to accept incoming requests</li>
						<li>where to read documents from</li>
						<li>how to allow/deny access to documents</li>
						<li>what to do with those documents</li>
						<li>how to return them in HTTP responses</li>
					</ul>
					<li>Rules might apply to the <link href="general-server-setup">whole server</link> or on a <link href="overriding-server-setup">per-directory basis</link></li>
				</ul>
			</slide>
			<slide id="general-server-setup">
				<title>General Server Setup</title>
				<ul>
					<li>Server start means reading the configuration file</li>
					<ul>
						<li>there typically is a compiled default location</li>
						<li>it is also possible to set the location ar runtime</li>
					</ul>
					<pre>/usr/local/apache/bin/httpd -f /usr/local/apache/conf/httpd.conf</pre>
					<li>Server start may fail due to a variety of reasons</li>
					<ul>
						<li>it is not allowed to use the specified network port</li>
						<li>some other program is already bound to the specified network port</li>
						<li>access to required files (e.g., log file) is not possible</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Restricting Access</title>
				<listing src="httpd.conf" line="45-53"/>
			</slide>
			<slide>
				<title>Document Root</title>
				<listing src="httpd.conf" line="185-189"/>
				<listing src="httpd.conf" line="213-245"/>
				<listing src="httpd.conf" line="248-253"/>
			</slide>
			<slide>
				<title>File Handling and Processing</title>
				<listing src="httpd.conf" line="398-405"/>
				<listing src="mime.types" line="531"/>
				<listing src="httpd.conf" line="445-451"/>
			</slide>
			<slide>
				<title>What's Going On?</title>
				<listing src="access.log" title="dret.net Access Log"/>
			</slide>
			<slide>
				<title>What Went Wrong?</title>
				<listing src="error.log" title="dret.net Error Log"/>
			</slide>
			<slide id="overriding-server-setup">
				<title>Overriding Server Setup</title>
				<ul>
					<li><code>httpd.conf</code> is the global server configuration</li>
					<ul>
						<li>it can be more reasonable to outsource certain configurations</li>
						<li>for community servers some users might want to add/change the configuration</li>
					</ul>
					<li>Apache allows to make configurations on a per-directory basis</li>
					<ul>
						<li><code href="http://httpd.apache.org/docs/2.2/howto/htaccess.html">.htaccess</code> files are read before a request is processed</li>
						<li>they can only change what has been allowed on <code href="http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride">AllowOverride</code></li>
						<li>using <code>.htaccess</code> has a noticeable performance impact (for high load)</li>
					</ul>
					<li><code>.htaccess</code> uses the same configuration syntax as <code>httpd.conf</code></li>
				</ul>
			</slide>
		</part>
 		<part id="security-concepts">
			<title>Security Concepts</title>
			<slide id="identification">
				<title>Identification</title>
				<ul>
					<li><em>Identity</em> is required for any non-anonymous communications</li>
					<ul>
						<li><em>groups</em> can have an identity (facebook members see more than non-members)</li>
						<li><em>pseudonyms</em> are <q>hidden identities</q> (the <q>real identity</q> is not visible)</li>
						<li><em>personal identity</em> should be tied to a person itself</li>
					</ul>
					<li><em>Proof of Identity</em> is important for any privileged operation</li>
					<ul>
						<li><em>signatures</em> and <em>seals</em> are traditional ways</li>
						<li>traditional ways are mostly protected by law (but not really safe)</li>
						<li>more modern ways often include technical methods for <link href="authentication"/></li>
					</ul>
					<li>Client identity on the Web can be bound in three ways:</li>
					<ol>
						<li>Computer (most of the time <q>identified</q> by an <link href="ip-address"/>)</li>
						<li>Browser (in the form of a stored <link href="cookies">cookie</link>)</li>
						<li>User (identified through some <link href="authentication">authentication method</link>)</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Authentication</title>
				<ul>
					<li><em>Authentication</em> is the process of verifying an identity</li>
					<ul>
						<li>the weakest form of authentication is simply <em>trust</em></li>
						<li>legal consequences can make it more risky to falsify authentication</li>
						<li>technical measures should make it hard or impossible to falsify authentication</li>
					</ul>
					<li>Authentication on the Web comes in different flavors</li>
					<ul>
						<li>implicitly by accessing a server from some <link href="ip-address"/> range</li>
						<li>presenting a <link href="cookies">cookie</link> from a previous formal authentication</li>
						<li>presenting a password as a proof of identity</li>
						<li>proving that you are owning additional authentication hardware (often <a href="http://en.wikipedia.org/wiki/Personal_identification_number">PIN</a>-enabled)</li>
					</ul>
					<li>Risk and potential damage should justify authentication methods</li>
				</ul>
			</slide>
			<slide id="authorization">
				<title>Authorization</title>
				<ul>
					<li><em>Authorization</em> is the question of allowing operations</li>
					<ul>
						<li><link href="identification"/> is necessary to identify the initiator</li>
						<li><link href="authentication"/> is necessary to verify the initiator's identity</li>
						<li>if the initiator is <em>authorized</em>, the operation can be performed</li>
					</ul>
					<li>Web pages often are <em>public</em> or <em>restricted</em></li>
					<ul>
						<li>public web pages do not require any identification (and thus authentication)</li>
						<li>restricted access Web pages can be group pages (internal company pages)</li>
						<li>personal access is another popular scenario (email, facebook, online banking)</li>
					</ul>
					<li>Web servers have well-defined ways of <link href="http-authentication">performing authentication</link></li>
				</ul>
			</slide>
		</part>
		<part>
			<title>HTTP Authentication</title>
			<slide>
				<title>HTTP Sessions</title>
				<ul>
					<li>HTTP is a stateless protocol</li>
					<ul>
						<li>each individual request is independent of others</li>
					</ul>
					<li>Authentication often is based on state/sessions</li>
					<ul>
						<li>users provide credentials and enter a <q>trusted state</q></li>
						<li>based on some method the <q>trusted state</q> can be left</li>
					</ul>
					<li><link href="cookies">Cookies</link> were invented to simulate sessions</li>
					<ul>
						<li>they can be set by servers and thus are state kept with the client</li>
						<li>cookies are popular for browsers but not so popular for other clients</li>
					</ul>
					<li>HTTP has its own methods of supporting authentication</li>
					<ul>
						<li>not used by many Web sites (because of browser inconveniences)</li>
						<li>a simple and standardized option for Web-based services</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Logging In</title>
				<ul>
					<li>Clients ask for a resource that is access controlled</li>
					<li>Servers respond with an HTTP header asking for authentication</li>
					<li>Clients ask the user to provide the required information</li>
					<li>The request is repeated with the user credentials</li>
					<li>Servers check for proper authorization and respond accordingly</li>
					<li>Clients are allowed to remember the credentials for the realm</li>
				</ul>
			</slide>
			<slide>
				<title>Logging Out</title>
				<ul>
					<li>You cannot logout because you never logged in</li>
					<ul>
						<li>HTTP has no session concept</li>
						<li>repeating authentication for each request is not an option</li>
						<li>clients store authentication credentials and repeat them for the user</li>
					</ul>
					<li>Logging out is entirely under the control of the client</li>
					<ul>
						<li>when does the client discards the credentials?</li>
						<li>easier to decide in APIs than in browser implementations</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Browser Controls</title>
				<img style="width : 90% ; margin : 2% ; " src="http-logout.png" title="Logging out of HTTP Authentication"/>
				</slide>
			<part>
				<title>Basic Authentication</title>
				<slide>
					<title>Configuration Steps</title>
					<ul>
						<li>Create a list of users and their passwords</li>
						<pre>htpasswd -c …/passwords.txt dret</pre>
						<li>Users and passwords are stored in a user file/database</li>
						<listing src="./src/basic/passwords.txt"/>
						<li>Configure the server to apply basic authentication</li>
						<listing src="./src/basic/.htaccess"/>
						<li>Control files by <a href="src/basic/basic.html">placing them in the appropriate directory</a></li>
					</ul>
				</slide>
				<slide>
					<title>First HTTP Request</title>
					<pre>GET /drectures/mobapp-spring10/src/basic/basic.html HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,de-de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/drectures/mobapp-spring10/src/basic/
If-Modified-Since: Wed, 07 Apr 2010 16:54:02 GMT
If-None-Match: "a00000002d8d8-160-483a868c94a7c"
Cache-Control: max-age=0

HTTP/1.1 401 Authorization Required
Date: Wed, 07 Apr 2010 17:55:05 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8i mod_autoindex_color PHP/5.2.6
WWW-Authenticate: Basic realm="Protected by Basic Authentication"
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en</pre>
				</slide>
				<slide>
					<title>Second HTTP Request</title>
					<pre>GET /drectures/mobapp-spring10/src/basic/basic.html HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,de-de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/drectures/mobapp-spring10/src/basic/
If-Modified-Since: Wed, 07 Apr 2010 16:54:02 GMT
If-None-Match: "a00000002d8d8-160-483a868c94a7c"
Cache-Control: max-age=0, max-age=0
Authorization: Basic ZHJldDpzdXBlcnNlY3JldA==

HTTP/1.1 304 Not Modified
Date: Wed, 07 Apr 2010 17:55:12 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8i mod_autoindex_color PHP/5.2.6
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Etag: "a00000002d8d8-160-483a868c94a7c"
X-Pad: avoid browser bug</pre>
				</slide>
				<slide>
					<title>Authentication Security</title>
					<ul>
						<li>Username/password are encoded in <a href="http://en.wikipedia.org/wiki/Base64">Base64</a></li>
						<ul>
							<li>an <em>encoding</em> is not an <em>encryption</em></li>
						</ul>
						<li><a href="http://www.motobit.com/util/base64-decoder-encoder.asp">Decoding Base64</a> is a very simple process</li>
						<ul>
							<li>an <em>encoding</em> is not an <em>encryption</em></li>
						</ul>
						<li>Basic authentication should never be used without <link href="https">HTTPS</link></li>
						<ul>
							<li>people will be broadcasting username/password on wireless networks</li>
							<li>they often try other username/password combinations as well</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>Digest Access Authentication</title>
				<slide>
					<title>Configuration Steps</title>
					<ul>
						<li>Configure the server to support digest access configuration</li>
						<listing src="httpd.conf" line="71"/>
						<li>Create a list of users and their passwords</li>
						<pre>htdigest -c …/passwords.txt "Protected by Digest Access Authentication" dret</pre>
						<li>Users and passwords are stored in a user file/database</li>
						<listing src="./src/digest/passwords.txt"/>
						<li>Configure the server to apply basic authentication</li>
						<listing src="./src/digest/.htaccess"/>
						<li>Control files by <a href="src/digest/digest.html">placing them in the appropriate directory</a></li>
					</ul>
				</slide>
				<slide>
					<title>First HTTP Request</title>
					<pre>GET /drectures/mobapp-spring10/src/digest/digest.html HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,de-de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/drectures/mobapp-spring10/src/digest/
If-Modified-Since: Wed, 07 Apr 2010 16:53:43 GMT
If-None-Match: "2a00000002d8e0-178-483a867a21110"
Cache-Control: max-age=0

HTTP/1.1 401 Authorization Required
Date: Wed, 07 Apr 2010 18:00:04 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8i mod_autoindex_color PHP/5.2.6
WWW-Authenticate: Digest realm="Protected by Digest Access Authentication", nonce="lsP1VKmDBAA=c14f7b87339d28d745e26b2911b0bef46792a929", algorithm=MD5, qop="auth"
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en</pre>
				</slide>
				<slide>
					<title>Second HTTP Request</title>
					<pre>GET /drectures/mobapp-spring10/src/digest/digest.html HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,de-de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/drectures/mobapp-spring10/src/digest/
If-Modified-Since: Wed, 07 Apr 2010 16:53:43 GMT
If-None-Match: "2a00000002d8e0-178-483a867a21110"
Cache-Control: max-age=0, max-age=0
Authorization: Digest username="dret", realm="Protected by Digest Access Authentication", nonce="lsP1VKmDBAA=c14f7b87339d28d745e26b2911b0bef46792a929", uri="/drectures/mobapp-spring10/src/digest/digest.html", algorithm=MD5, response="00067dc79112f87c811e23a36ec4a5ed", qop=auth, nc=00000001, cnonce="be2bd6d9be1058b4"

HTTP/1.1 304 Not Modified
Date: Wed, 07 Apr 2010 18:00:11 GMT
Server: Apache/2.2.9 (Win32) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8i mod_autoindex_color PHP/5.2.6
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Etag: "2a00000002d8e0-178-483a867a21110"
X-Pad: avoid browser bug</pre>
				</slide>
				<slide>
					<title>Authentication Security</title>
					<ul>
						<li>Username/password are not transmitted in the response</li>
						<li>401 response contains a <em>nonce</em> for authentication</li>
						<ul>
							<li>nonce values allow to prevent replay attacks</li>
							<li>realm and nonce are required to calculate credentials</li>
						</ul>
						<li>Client packages credentials in a <em>secure way</em></li>
						<ul>
							<li>username, realm, and password are turned into a hash value</li>
							<li>request method and request URI are turned into a hash value</li>
							<li>these two hashes and the nonce are hashed</li>
						</ul>
						<li>Digest access authentication implementations differ</li>
						<ul>
							<li>security depends on the exact feature set used by client and server</li>
							<li>using <link href="https">HTTPS</link> is a good idea in this scenario</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
	</presentation>
	<presentation id="security">
		<title short="Security">Security Mechanisms</title>
		<date>2010-04-09</date>
        <toc class="reading"><a href="http://cacm.acm.org/magazines/2009/8/34494-browser-security/fulltext" title="Browser Security: Lessons from Google Chrome, Charles Reis, Adam Barth, Carlos Pizano, Communications of the ACM, Vol. 52 No. 8, Pages 45-49, August 2009">Browser Security</a></toc>
        <toc class="resources"><a href="http://en.wikipedia.org/wiki/Internet_security" title="Wikipedia: Internet Security">Security</a>&#160;· <a href="http://en.wikipedia.org/wiki/Internet_privacy" title="Wikipedia: Internet Privacy">Privacy</a></toc>
		<toc class="abstract">For the HTTP authentication methods introduced in the last lecture, some fundamental cryptographic methods and protocols already have been taking for granted. In this lecture, we look a bit more systematically at the fundamental <em>cryptographic methods</em> (hash sums, one-way functions, symmetric encryption, asymmetric encryption) and how these are combined into <em>cryptographic protocols</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="iphoneos4">
			<title>Current Events</title>
			<slide>
				<title>iPhone OS 4</title>
				<img src="iphone-os-4.jpg" style="height : 65% ; margin : 4% ; " href="http://news.cnet.com/8301-13579_3-20001876-37.html/"/>
			</slide>
			<slide>
				<title>Multitasking</title>
				<img src="iphone-os-4-multitasking.jpg" style="height : 65% ; margin : 4% ; " href="http://news.cnet.com/8301-13579_3-20001876-37.html/" title="Hello, Skype"/>
			</slide>
			<slide>
				<title>Multitasking Services</title>
				<ol>
					<li>Audio (e.g., Pandora)</li>
					<li>Voice over IP (e.g., Skype)</li>
					<li>Location (e.g., Loopt, Navigation)</li>
					<li>Push Notifications</li>
					<li>Local Notifications</li>
					<li>Task Completion</li>
					<li>Fast App Switching (<q>sleep</q>)</li>
				</ol>
			</slide>
			<slide>
				<title>Background Audio</title>
				<img src="iphone-os-4-audio.jpg" style="height : 65% ; margin : 4% ; " href="http://news.cnet.com/8301-13579_3-20001876-37.html/" title="Hello, Pandora"/>
			</slide>
			<slide>
				<title>Location Services</title>
				<img src="iphone-os-4-location.jpg" style="height : 65% ; margin : 4% ; " href="http://news.cnet.com/8301-13579_3-20001876-37.html/" title="Hello, Stalker"/>
			</slide>
			<slide>
				<title>Advertising</title>
				<img src="iphone-os-4-iad.jpg" style="height : 65% ; margin : 4% ; " href="http://news.cnet.com/8301-13579_3-20001876-37.html/" title="Location-Based Ads"/>
			</slide>
			<slide>
				<title>Social Gaming</title>
				<img src="iphone-os-4-gaming.jpg" style="height : 65% ; margin : 4% ; " href="http://news.cnet.com/8301-13579_3-20001876-37.html/" title="Good bye, OpenFeint"/>
			</slide>
		</part>
 		<part id="security-101">
			<title>Security 101</title>
			<slide>
				<title>Cryptography</title>
				<ul>
					<li>Cryptography is structured into different layers</li>
					<ul>
						<li>layering is a well-established principle for <em>separation of concerns</em></li>
					</ul>
					<li><em>Cryptographic primitives</em> implement very basic functionality</li>
					<ul>
						<li>changes and advancements in this area are limited to very specialized researchers</li>
						<li>it is easy to make fatal mistakes which then compromise everything built on top if it</li>
					</ul>
					<li><em>Cryptographic protocols</em> assemble primitives into application-level solutions</li>
					<ul>
						<li>primitives solve very basic security problems (fingerprints, encryption, …)</li>
						<li>protocols combine these into applications (digital signatures, secure communications, …)</li>
						<li><em>installing trusted applications</em> is a common mobile security scenario</li>
					</ul>
				</ul>
			</slide>
			<part id="hash-functions">
				<title>Hash Functions</title>
				<slide id="hash">
					<title>Simple Hash Functions</title>
					<ul>
						<li>Hashes (or <em>message digests</em>) are well-known in computer science</li>
						<li><em>Hash values</em> are of fixed and short length and make it easier to compare data</li>
						<li><em>Collisions</em> are the most problematic case in hash algorithms</li>
						<ul>
							<li><q>length in bytes is even/uneven</q>: risk of collision is 50%</li>
							<li><q>length in bytes</q>: collisions happen when data is simply replaced</li>
						</ul>
						<li>Hashing is often done on an ad-hoc basis</li>
						<ul>
							<li><em>lengths</em> are a form of hashes</li>
							<li><em>time stamps</em> are a form of hashes</li>
						</ul>
						<li>Hashing is also used for computing error correction codes</li>
						<ul>
							<li>many technologies (hard drives, networks, …) use <em href="http://en.wikipedia.org/wiki/Cyclic_redundancy_check">Cyclic Redundancy Code (CRC)</em> hashes</li>
							<li>error correction codes computation has to be done very fast</li>
						</ul>
					</ul>
				</slide>
				<slide id="one-way-function">
					<title>One-Way Function</title>
					<ul>
						<li>One-way functions are cryptographically safe <link href="hash">hashes</link> (a.k.a. <em>cryptographic hash</em>)</li>
						<ul>
							<li>very hard to find an input producing a given output</li>
							<li>very hard to find two inputs producing the same output (<q>collision</q>)</li>
							<li>small changes in input should cause entirely different output</li>
						</ul>
						<li><em href="http://en.wikipedia.org/wiki/MD5">MD5</em> has been a very popular cryptographic hash</li>
						<ul>
							<li>MD5 turns data into a 128bit hash value (often encoded as 32 hex characters)</li>
							<li>various security flaws have been discovered over the years</li>
							<li><q>MD5 Hash Function</q> → <q>e367cdcfd2e16f28e81bbc58c9d3339c</q></li>
						</ul>
						<li><em href="http://en.wikipedia.org/wiki/SHA">SHA</em> is the most popular cryptographic hash in use today</li>
						<ul>
							<li>SHA-1 turns data into a 160bit hash value (often encoded as 40 hex characters)</li>
							<li><q>SHA-1 Hash Function</q> → <q>afd38b77186afba44123093827c2e0f3732726c4</q></li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="secret-key">
				<title>Secret-Key Cryptography</title>
				<slide>
					<title>Plausible Encryption</title>
					<ul>
						<li>Secret-Key is was most people think of when thinking of encryption</li>
						<ul>
							<li><em>symmetric cryptography</em> is another popular term</li>
						</ul>
						<li>One key for encryption and decryption</li>
						<li>Revealing the key makes encrypted data openly readable</li>
						<ul>
                            <li>there must be a secure channel to transport keys, such as <a href="http://en.wikipedia.org/wiki/Diplomatic_bag">diplomatic pouches</a></li>
						</ul>
						<li>Good for long-term relationships with few partners</li>
						<ul>
							<li>exchange secret keys as part of the initial setup of a relationships</li>
							<li>adding partners requires a <em>secure channel</em> for key exchange</li>
							<li>changing keys requires a <em>secure channel</em> for key exchange</li>
						</ul>
						<li>Almost impractical in an environment with many ad-hoc partners</li>
					</ul>
				</slide>
				<slide>
					<title>Notice the Arrow</title>
					<img style="width : 90% ; margin : 2% ; " src="secret-key.gif" title="Secret-Key Cryptography"/>
				</slide>
			</part>
			<part id="public-key">
				<title>Public-Key Cryptography</title>
				<slide>
					<title>Implausible Encryption</title>
					<ul>
						<li>Public-Key intuitively is hard to accept as a concept</li>
						<ul>
							<li><em>asymmetric cryptography</em> is another popular term</li>
						</ul>
						<li>Key pairs of one public and one secret key</li>
						<ul>
							<li><em>key generation</em> is the process of generating these key pairs</li>
						</ul>
						<li>The public key can be made available to the public</li>
						<ul>
							<li>only the secret key can do the inverse operation of the public key</li>
						</ul>
						<li>Good for short-term relationships with many partners</li>
						<ul>
							<li>publish your public key so that it can be used worldwide</li>
							<li>everybody can encrypt data using the public key</li>
							<li>only the owner of the secret can can decrypt the message and read it</li>
						</ul>
						<li>Computationally expensive and not good for a large amounts of data</li>
					</ul>
				</slide>
				<slide>
					<title>No Arrow Here …</title>
					<img style="width : 90% ; margin : 2% ; " src="public-key-secret-encrypt.gif" title="Public-Key Cryptography (Encrypting with Secret Key)"/>
				</slide>
			</part>
			<part id="crypto-protocols">
				<title>Cryptographic Protocols</title>
				<slide>
					<title>Building Secure Applications</title>
					<ul>
						<li><em>Cryptographic primitives</em> in most cases are not sufficient</li>
						<ul>
							<li>they provide basic functionality for fundamental tasks</li>
							<li>they must by combined to provide solutions for real-world problems</li>
						</ul>
						<li>Typical problem #1: How to ensure key authenticity</li>
						<ul>
							<li>with insecure keys, the majority of cryptographic methods is worthless</li>
						</ul>
						<li>Typical problem #2: How to communicate securely without shared keys</li>
						<ul>
							<li>many interesting scenarios are based on ad-hoc interactions</li>
							<li>secret-key does not work, public-key needs to verify the peer</li>
						</ul>
						<li>Typical problem #3: How to check authenticity and integrity of data</li>
						<ul>
							<li>integrity can be done with checksums, but these could be forged</li>
							<li>authenticity needs a cryptographically secure way of combining identity and data</li>
						</ul>
					</ul>
				</slide>
				<slide id="certificate">
					<title>Certificate</title>
					<ul>
						<li>Certificates are digital signatures issued by a trusted party</li>
						<ul>
							<li>most digital signatures are created with certified public keys</li>
							<li>this means the digital signature is created based on a digitally signed key</li>
						</ul>
						<li>Who can you trust on the Web?</li>
						<ul>
							<li>trust can only start to grow based on initial trust in something</li>
							<li>many systems come with pre-installed trust (<em>root certificates</em>)</li>
							<li>certificates from other issuers will cause <a href="https://katapultmedia.com/">browsers to complain</a></li>
						</ul>
						<li>Certificates (like domain names) are a very easy way to make money</li>
						<ul>
							<li>in theory there are different levels of certificates with different levels of identity checking</li>
							<li>in practice most sites choose the cheapest one that does not give an error message</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Creating a Digital Signature</title>
					<img style="height : 70% ; margin : 2% ; " src="signature-sign.jpg" href="http://en.wikipedia.org/wiki/Digital_signature"/>
				</slide>
				<slide>
					<title>Verifying a Digital Signature</title>
					<img style="height : 70% ; margin : 2% ; " src="signature-verify.jpg" href="http://en.wikipedia.org/wiki/Digital_signature"/>
				</slide>
			</part>
		</part>
	</presentation>
	<presentation id="authentication">
		<title short="Authentication">Authentication</title>
		<date>2010-04-12</date>
		<toc class="resources"><a href="http://support.mozilla.com/en-US/kb/Options+window" title="Firefox Options for Security and Privacy">Browser Options</a>&#160;· <a href="http://en.wikipedia.org/wiki/Https" title="Wikipedia: HTTPS">HTTPS</a>&#160;· <a href="http://tools.ietf.org/html/rfc2818" title="IETF RFC 2818: HTTP over TLS (HTTPS)">HTTPS Spec</a>&#160;· <a href="http://oauth.net/">OAuth</a></toc>
		<toc class="abstract">Continuing the topic of security in mobile settings, we look at the two main applications in mobile security, which are securing communications with SSL/TLS in HTTP, and securing application code via digital signatures. Another important concept in access control and authentication is that of third-party access to access-controlled resources. We look at <em>OAuth</em>, which is one way of managing access in scenarios where applications want to gain access to resources that are hosted by other services and are access-controlled.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
 		<part>
			<title>Browser Security &amp; Privacy</title>
			<slide>
				<title>Trust and Security on the Web</title>
				<ul>
					<li>Web-based applications introduce many risks</li>
					<ul>
						<li>do you trust your browser? (it may not safeguard your information)</li>
						<li>do you trust your computer? (it may have a virus)</li>
						<li>do you trust your network? (it may be monitored on various levels)</li>
						<li>do you trust the server? (it may be a fake <a href="http://en.wikipedia.org/wiki/Phishing">phishing</a> server)</li>
						<li>who do you trust, regarding what, and why? and what does it mean?</li>
					</ul>
					<li>Most of these risks are amplified by the Web's scale</li>
					<ul>
						<li>phishing and spamming only work because the Web makes fraud more effective</li>
					</ul>
					<li>Controlling Web access is important for safe browsing</li>
					<ul>
						<li>trusting shared browsers is risky (they may store logins and cache pages)</li>
						<li>trusting the network can be risky (more and more networks are wire-tapped)</li>
						<li>trusting the server is risky (phishing and poor server security)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Privacy Options</title>
				<img src="firefox-options-privacy.png" style="height : 70% ; margin : 2% ; " title="Firefox Options: Privacy"/>
			</slide>
			<slide>
				<title>Security Options</title>
				<img src="firefox-options-security.png" style="height : 70% ; margin : 2% ; " title="Firefox Options: Security"/>
			</slide>
			<slide>
				<title>Encryption Options</title>
				<img src="firefox-options-encryption.png" style="height : 70% ; margin : 2% ; " title="Firefox Options: Encryption"/>
			</slide>
		</part>
		<part id="https">
			<title short="HTTPS">HTTP over SSL (HTTPS)</title>
			<slide>
				<title>Secure Communications</title>
				<ul>
					<li><link href="public-key">Public-Key cryptography</link> is computationally expensive</li>
					<ul>
						<li>it is possible to encrypt all traffic using asymmetric key pairs</li>
						<li>this generates considerably more load on the server side</li>
					</ul>
					<li>Combining <link href="public-key">public-key</link> and <link href="secret-key">secret-key</link> cryptography</li>
					<ol>
						<li>check the public key for authenticity (using a <link href="certificate"/>)</li>
						<li>generate a key for a symmetric encryption scheme</li>
						<li>use the public key to securely transmit the generated key</li>
						<li>use the generated key for securely transmitting the payload</li>
					</ol>
					<li>Combines the advantages of both methods</li>
					<ul>
						<li>the ability of public-key algorithms to work without a secure channel (<q>handshake</q>)</li>
						<li>the lower complexity of secret-key algorithms (<q>record layer</q>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP and Security</title>
				<ul>
					<li>HTTP sends clear-text messages</li>
					<li>Making HTTP secure requires additional mechanisms</li>
					<li>Encryption is done by a layer on top of TCP</li>
					<ul>
						<li><em>Secure Sockets Layer (SSL)</em> is the protocol layer invented by Netscape</li>
						<li><em>Transport Layer Security (TLS)</em> is the standardized Internet version</li>
						<li>TLS adds more encryption schemes and more flexibility</li>
					</ul>
					<li>Lower-level methods may also provide encryption</li>
					<ul>
						<li><em>Virtual Private Networks (VPN)</em> provide IP-based encryption</li>
						<li><em>WEP</em> and <em>WPA</em> provide network interface encryption</li>
						<li>lower-level methods typically are not end-to-end (i.e., browser/server)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP and SSL</title>
				<img style="width : 90% ; margin : 2% ; " src="https.gif" title="HTTP and SSL"/>
			</slide>
			<slide>
				<title>Preconfigured Trust</title>
				<ul>
					<li>Clients have a long list of pre-installed root certificates</li>
					<ul>
						<li>who is managing HTTP/HTTPS/SSL/TLS? the client application or the device?</li>
					</ul>
					<li>A <em>Certification Authority (CA)</em> can issue trusted certificates</li>
					<ul>
						<li>there is no real definition of what a CA is supposed to do</li>
						<li>CAs may have the right to delegate CA status to other CAs</li>
						<li>CAs may have different <q>levels</q> of certificates</li>
					</ul>
					<li>Updated CA lists often are part of system or browser updates</li>
					<ul>
						<li>Microsoft and Apple include CA lists in system updates</li>
						<li>3rd party browsers sometimes manage their own CA lists</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Certificates in Firefox</title>
				<img src="certificates-firefox.png" style="height : 70% ; margin : 2% ; " title="Firefox Certificate Manager"/>
			</slide>
			<slide>
				<title>Certificates in Opera</title>
				<img src="certificates-opera.png" style="height : 70% ; margin : 2% ; " title="Opera Certificate Manager"/>
			</slide>
			<slide>
				<title>Certificates in Windows (i.e., IE/Safari/Chrome)</title>
				<img src="certificates-windows.png" style="height : 70% ; margin : 2% ; " title="Windows Certificate Manager"/>
			</slide>
		</part>
		<part>
			<title>Application Security</title>
			<slide>
				<title>Web Application Security</title>
				<ul>
					<li>Browsers are supposed to provide a <em>safe sandbox</em></li>
					<ul>
						<li>broken code cannot harm the computer</li>
						<li>malicious code cannot steal data from the computer</li>
						<li>malicious code cannot steal data from other sites</li>
					</ul>
					<li>Browsers should not be able to lie to their users</li>
					<ul>
						<li>the address bar shows users what they are looking at</li>
						<li>the <q>lock icon</q> allows users to inspect security</li>
					</ul>
					<li>Introducing <q>trusted 3rd parties</q> in this scenario is not easy</li>
					<ul>
						<li>any form of <q href="http://www.verisign.com/trust-seal/faq/index.html">external site verification</q> can easily be forged</li>
						<li>the Web guarantees connectivity to a site and not a well-behaving site</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Trusted Computing</title>
				<ul>
					<li>Developed to avoid the threats of malware</li>
					<ul>
						<li>programs must be signed before they can be executed</li>
						<li>basic procedures are built into the hardware of the computer</li>
						<li>it is impossible for such a computer to execute untrusted code</li>
					</ul>
					<li>Often data storage also is managed cryptographically</li>
					<ul>
						<li>only trusted code gets access to managed data</li>
						<li>data is never stored unencrypted and thus cannot be easily stolen</li>
						<li>security vs. convenience and <q>lock-in</q> are important questions</li>
					</ul>
					<li><em>Digital Rights Management (DRM)</em> was also pulled into the platform</li>
					<ul>
						<li>content owners would have much better control over content use</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Native Application Security</title>
				<ul>
					<li>The return of the <q>trusted computing platform</q></li>
					<ul>
						<li>Apple's iPhone implements what Microsoft dreamed of 10 years ago</li>
					</ul>
					<li>Only software submitted to and verified by Apple can be executed</li>
					<ol>
						<li>signing up as a developer creates an identity verified by Apple</li>
						<li>submitting an application means that it is signed with that identity</li>
						<li>accepting the application means that Apple is signing with its identity</li>
						<li>software installation only works with signed installation packages</li>
					</ol>
					<li><q>Jailbreaking</q> the iPhone is disabling this authentication chain</li>
					<ul>
						<li>applications need not to be signed by Apple anymore</li>
					</ul>
					<li>Android has a simple user setting to allow <q>unsigned</q> applications</li>
					<ul>
						<li>installation packages do not have to be signed at all</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="oauth">
			<title>OAuth</title>
			<slide>
				<title>Open Authentication</title>
				<img src="oauth.png" style="width: 15% ; float : right ; margin : 0 1em 2em 2em ; " href="http://oauth.net/"/>
				<ul>
					<li>Applications often use resources from a variety of sources</li>
					<ul>
						<li>browser-based applications often are called <q>mash-ups</q></li>
						<li>server-based applications might be called <q>mash-apps</q></li>
					</ul>
					<li>Browser-based applications might run into browser restrictions</li>
					<ul>
						<li><link href="jsonp">JSONP</link> is one way to get around browser restrictions</li>
						<li>setting up proxies is another way for achieving the same goal</li>
					</ul>
					<li>Access control for 3rd party resources is a common scenario</li>
					<ul>
						<li>granting access without revealing the access credentials</li>
						<li>give them a token instead of giving them credentials</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Delegation vs. Federation</title>
				<ul>
					<li><em>Delegated Authentication</em> allows services to delegate authentication</li>
					<ul>
						<li>services delegate user authentication to other services</li>
						<li>the set of authentication services often is small and fixed</li>
					</ul>
					<li><em>Federated Authentication</em> allows services to share identities</li>
					<ul>
						<li>authentication is done locally but the account information is openly available</li>
					</ul>
					<li>Credit card procedures provide real-world examples for both methods</li>
					<ul>
						<li>using generic cards is federated: stores accept payments when approved by Visa</li>
						<li>using branded cards is delegated: cards have to be authenticated by the brand</li>
					</ul>
					<li><em>OpenID</em> is a popular <em>federated authentication scheme</em></li>
					<ul>
						<li>it's actually <em>open identification</em> and not all implementations are federated</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>OAuth Control Flow</title>
				<img src="oauth-diagram.png" style="height : 70% ; margin : 2% ; " href="http://oauth.googlecode.com/svn/spec/core/1.0/"/>
			</slide>
			<slide>
				<title>OAuth Process</title>
				<ul>
					<li>OAuth supports the <em>3-legged authentication scenario</em></li>
					<ul>
						<li><em>users</em> are interacting with applications</li>
						<li><em>service providers</em> are providing access-controlled resources</li>
						<li><em>consumers</em> need access to the resources on behalf of the user</li>
					</ul>
					<li>OAuth uses a scheme with redirects and authentication tokens</li>
					<ol>
						<li>users access the consumer who then need access to the service provider</li>
						<li>consumers get a <em>request token</em> from the provider</li>
						<li>consumers redirect the user to the service provider</li>
						<li>users authenticate with the provider based on the request token</li>
						<li>successful authentication means that the access token is marked</li>
						<li>the user is redirected back to the URI provided in the first redirect</li>
						<li>the consumer exchanges the request token into an <em>access token</em></li>
						<li>the type of access allowed by the token is controlled by the provider</li>
					</ol>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="constraints">
		<title short="Constraints">Constraints of Mobile Applications</title>
		<date>2010-04-14</date>
		<toc class="resources"></toc>
		<toc class="abstract">Mobile application development faces the same performance challenges as application development in general, which means that performance considerations have to be an integral part of any real-world application design. However, on mobile devices, the challenges related to performance issues are quite a bit bigger, because the runtime platforms may be limited in their functionality, the platforms are inherently limited in their resources (mostly processing power and memory), and the devices often have connectivity that may be substantially slower than best-case scenarios, or may even be intermittent.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Mobile Application Design</title>
			<blockquote>Design depends largely on constraints.</blockquote>
			<p class="quotenote"><a href="http://en.wikipedia.org/wiki/Charles_and_Ray_Eames">Charles Eames</a>, <a href="http://www.scielo.cl/pdf/arq/n49/art11.pdf"><q>What is Design?</q>, An Interview with Charles Eames</a></p>
		</slide>
		<part id="bottlenecks">
			<title>Performance Bottlenecks</title>
			<slide>
				<title>Client-Side Constraints</title>
				<ul>
					<li>Limitations of the <em>Mobile Platform</em></li>
					<ul>
						<li>general limitations of the mobile platform (<q>HTML5 has no camera API</q>)</li>
						<li>specific limitations of one implementation of that platform (<q>Firefox has no SQL support</q>)</li>
					</ul>
					<li>Limitations of the runtime environment</li>
					<ul>
						<li>memory is a problem on all mobile platforms (no support for <em>virtual memory</em>)</li>
						<li>limited processing power is a problem on all mobile platforms</li>
						<li>smartphones are increasingly used as general-purpose computers</li>
					</ul>
					<li><em>Layering</em> does have some problems on mobile devices</li>
					<ul>
						<li>layering creates inefficiencies (JavaScript on iPhone 100 times slower)</li>
						<li>layering takes away possibilities for optimization (UI and execution)</li>
						<li>some platforms oppose/prevent layering out of general principle</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Client Devices</title>
				<ul>
					<li>iPhone hardware comes in two different memory configurations</li>
					<ul>
						<li>first generation iPhones have 128MB of RAM</li>
						<li>3G and 3GS iPhones have 256MB of RAM</li>
					</ul>
					<li>Android hardware is less predictable and varies more widely</li>
					<ul>
						<li>the <link href="droid">Droid</link> has 256MB of RAM</li>
						<li>for many devices getting hardware specs is almost impossible</li>
					</ul>
					<li>Bundling data might not always be a good idea</li>
					<ul>
						<li>Android applications can only be installed in the onboard memory (Droid: 512MB)</li>
						<li>applications requiring a lot of local data should store it separately</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Network Constraints</title>
				<ul>
					<li>Network connectivity is potentially slow and unreliable</li>
					<ul>
						<li>applications should be designed to work well with a slow network</li>
						<li>applications should be designed to behave reasonably with no network</li>
					</ul>
					<li>Offline behavior largely depends on the application scenario</li>
					<ul>
						<li>considering offline behavior in use cases should always be included</li>
					</ul>
					<li>Enabling <em>any</em> Web-app for offline use may be a good idea</li>
					<ul>
						<li>not all browsers support offline applications</li>
						<li>browsers may start removing cached applications more aggressively</li>
						<li><link href="appcache">HTML5 AppCache</link> is only a caching hint for a browser</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Native vs. Offline Web</title>
				<ul>
					<li>Native applications are under control of the user</li>
					<ul>
						<li>users decide what to install, update, and uninstall</li>
						<li>the only networking part is how to get the installation package</li>
					</ul>
					<li>Web-based applications are under control of the server</li>
					<ul>
						<li>services decide to provide a manifest and become off-line capable</li>
						<li>browsers implement some strategy for caching those applications</li>
						<li>updates have to be initiated and implemented by the service</li>
					</ul>
					<li>Challenges for offline Web-based applications</li>
					<ul>
						<li>giving users better control over what to cache</li>
						<li>caching data probably should be handled different from caching code</li>
						<li>allowing applications to expose <q>widget-like</q> behavior</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="client-side-analysis">
			<title>Client-Side Performance Analysis</title>
			<slide id="in-app-analytics">
				<title>In-App Analytics</title>
				<ul>
					<li>Analytics are useful for a variety of purposes</li>
					<ul>
						<li>they allow to track user behavior and identify possible improvements</li>
						<li>they allow to track application behavior and identify possible problems</li>
						<li>they are important for all kinds of business-oriented analyses</li>
					</ul>
					<li><em>Google Analytics</em> is the most popular service for Web-based analytics</li>
					<ul>
						<li>Web pages embed code hosted by Google Analytics</li>
						<li>scripting collects information which is collected by Google Analytics</li>
						<li>Web masters can access Web-based tools for accessing the collected data</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Google Analytics</title>
				<img src="google-analytics.png" style="height : 70% ; margin : 2% ; " title="Google Analytics of dret.net"/>
			</slide>
			<slide>
				<title>Pinch Media</title>
				<img src="pinchmedia-state.jpg" style="height : 70% ; margin : 2% ; " title="Analytics with Pinch Media" href="http://www.pinchmedia.com/"/>
			</slide>
			<slide>
				<title>Browser-Based Analysis</title>
				<ul>
					<li>Web-based applications run in standardized implementations</li>
					<ul>
						<li>users use the same resources regardless of the implementation</li>
						<li>using <q>browser-based debugging</q> yields cross-platform results</li>
					</ul>
					<li>Client-side analysis can generate many interesting analyses</li>
					<ul>
						<li>is the scripting code distributed across many JavaScript files?</li>
						<li>would it be possible to minify the JavaScript code?</li>
						<li>is the CSS code distributed across many CSS files?</li>
						<li>would it be possible to minify the CSS code?</li>
						<li>can the images be compressed more effectively?</li>
						<li>are components served with useful HTTP metadata?</li>
						<li>are components served in a compressed format?</li>
						<li>does the site use cookies?</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Browser Tools</title>
				<img src="yslow-stats.png" style="height : 70% ; margin : 2% ; " title="YSlow Analysis of Web Content"/>
			</slide>
			<slide id="server-side-analytics">
				<title>Server-Side Analysis</title>
				<ul>
					<li>Less intrusive but more limited than <link href="in-app-analytics"/></li>
					<ul>
						<li>all requests go to the server-side (unless there is a CDN)</li>
						<li>server-side analysis is able to capture client requests</li>
					</ul>
					<li>Server logs are the simplest way of gathering usage data</li>
					<ul>
						<li>in the simplest scenario log files are written by the server</li>
						<li>one entry per request with a configurable set of fields in the entry</li>
					</ul>
					<li>More sophisticated scenarios write log data to a database</li>
					<ul>
						<li>can be very convenient for immediate analysis and query support</li>
						<li>can be very risky because database writing tends to be slow</li>
					</ul>
					<li>Most scenarios use simple writing and delayed analysis</li>
					<ul>
						<li>entries are added to simple text-based files</li>
						<li>log files are rotated on a regular basis</li>
						<li>completed log files are processed for traffic analysis</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="speed">
		<title short="Speed">Speeding Up Mobile Applications</title>
		<date>2010-04-16</date>
		<toc class="resources"><a href="http://developer.yahoo.com/performance/rules.html" title="Best Practices for Speeding Up Your Web Site">Best Practices</a>&#160;· <a href="http://www.mnot.net/cache_docs/" title="Caching Tutorial for Web Authors and Webmasters">Caching Tutorial</a></toc>
		<toc class="abstract">In order to speed up mobile applications, the optimization of network traffic often is one of the areas where significant improvements can be achieved. Since most network traffic uses HTTP, it is important to understand how HTTP caching works, and how servers can be configured to make caching work more effectively. However, since servers have no control over the clients and possible HTTP intermediaries, it is also important to understand the general architecture of HTTP caching, and how applications may or may not have good caching support on the platform they are built on.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="server-side-analysis">
			<title>Server-Side Performance Analysis</title>
			<slide>
				<title>Server Logs</title>
				<img src="server-log.png" style="height : 70% ; margin : 2% ; "/>
			</slide>
			<slide>
				<title>Connecting to the Server</title>
				<img src="putty.png" style="height : 70% ; margin : 2% ; " href="http://en.wikipedia.org/wiki/PuTTY"/>
			</slide>
			<slide>
				<title>Log File Display</title>
				<ul>
					<li>Navigating to the log file directory</li>
					<pre>cd ~/mobapps-logs</pre>
					<li>Apache writes two log files</li>
					<ul>
						<li><code>mobapps_access_log</code> is the access log of the server</li>
						<li><code>mobapps_error_log</code> is the error log of the server</li>
						<li>the structure of the entries is <a href="http://httpd.apache.org/docs/2.2/logs.html">defined in the server configuration</a></li>
					</ul>
					<li>Displaying the lines added to the access log</li>
					<pre>tail -f mobapps_access_log</pre>
					<li>Displaying and filtering the lines added to the access log</li>
					<pre>tail -f mobapps_access_log | grep "/~dret"</pre>
				</ul>
			</slide>
			<slide>
				<title>MobApps Server Logs</title>
				<img src="server-log-mobapps.png" style="height : 70% ; margin : 2% ; "/>
			</slide>
			<slide>
				<title>Server Log Analysis</title>
				<img src="log-analysis.png" style="height : 70% ; margin : 2% ; " href="http://www.thefreecountry.com/webmaster/loganalyzers.shtml"/>
			</slide>
		</part>
		<part>
			<title>HTTP Caching</title>
			<slide>
				<title>Resource Orientation</title>
				<ul>
					<li><link href="rest">REST</link>'s focus on resources is good for caching</li>
					<ul>
						<li><em>resource representations</em> are sent in HTTP messages and can be cached</li>
						<li><em>HTTP methods</em> allow caching to be used only when appropriate</li>
					</ul>
					<li>HTTP is supposed to supply <em>useful metadata</em> in HTTP messages</li>
					<ul>
						<li>some HTTP headers are about the client or server agent</li>
						<li>some HTTP headers are about the entity contained in the message</li>
						<li>some HTTP headers serve general purposes</li>
					</ul>
					<li>Most applications require a mix of static and dynamic resources</li>
					<ul>
						<li>some resources <q>never</q> change (code and chrome)</li>
						<li>some resource classes are constantly growing (your Flickr images)</li>
						<li>some resources are ephemeral (any representation based on time)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Cache Locations</title>
				<ul>
					<li>HTTP allows caches to exist in various locations</li>
					<ul>
						<li><em>reverse proxies</em> are used for removing load from application servers</li>
						<li><em>proxy caches</em> are used for making the network more effective</li>
						<li><em>client caches</em> are used for making the client work faster</li>
					</ul>
					<li>Caching in many cases is not (easily) predictable</li>
					<ul>
						<li>caching depends on the scenario but always needs HTTP header information</li>
						<li>being a well-behaving HTTP citizen is a good idea</li>
						<li>caches should not change application behavior (it is just optimization)</li>
					</ul>
					<li><em>Client Caches</em> can be provided by platforms or applications</li>
					<ul>
						<li>many desktop browsers have their own HTTP implementations and caches</li>
						<li>mobile (and modern) platforms should move HTTP (and caching) into the platform</li>
					</ul>
				</ul>
			</slide>
			<slide id="flickr-web">
				<title>Caching in the Platform</title>
				<img src="flickr-web.png" style="height : 70% ; margin : 2% ; " href="http://www.flickr.com/photos/dret/"/>
			</slide>
			<slide>
				<title>HTTP Metadata</title>
				<pre href="http://www.flickr.com/photos/dret/4519445803/sizes/l/">GET /4026/4519445803_06922b9171_b.jpg HTTP/1.1
Host: farm5.static.flickr.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,de-de;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.flickr.com/photos/dret/4519445803/sizes/l/

HTTP/1.1 200 OK
Date: Fri, 16 Apr 2010 17:02:20 GMT
Content-Type: image/jpeg
Connection: keep-alive
Server: Apache/2.0.52 (Red Hat)
Cache-Control: max-age=315360000
Expires: Mon, 28 Jul 2014 23:30:00 GMT
Last-Modified: Wed, 14 Apr 2010 04:57:32 GMT
Accept-Ranges: bytes
Content-Length: 361084
X-Cache: MISS from photocache510.flickr.gq1.yahoo.com
X-Cache-Lookup: MISS from photocache510.flickr.gq1.yahoo.com:81
Via: 1.1 photocache510.flickr.gq1.yahoo.com:81 (squid/2.7.STABLE6)</pre>
			</slide>
			<slide id="flickr-iphone">
				<title>Caching in the Application</title>
				<img src="flickr-iphone.jpg" style="height : 70% ; margin : 2% ; " href="http://blog.flickr.net/en/2009/09/10/the-new-flickr-iphone-app/"/>
			</slide>
			<slide>
				<title>Caching in the Cloud</title>
				<img src="opera-turbo.jpg" style="height : 70% ; margin : 2% ; " href="http://www.opera.com/business/solutions/turbo/" title="Opera Mini and Opera Turbo"/>
			</slide>
			<slide>
				<title>Cache-Friendly Services</title>
				<ul>
					<li>Do not use aliases (different URIs for the same resource)</li>
					<li>Reuse content whenever possible (no copies of the same resource)</li>
					<ul>
						<li>reuse has to be Web-friendly (symlinks save disk space but are not cache-friendly)</li>
					</ul>
					<li>Serve static content with long expiration times</li>
					<li>Serve dynamic content with synchronized expiration times</li>
					<ul>
						<li>even dynamic content often does not expire immediately</li>
					</ul>
					<li>Avoid touching all files on your hard disk</li>
					<ul>
						<li>this will update all timestamps and make cached copies invalid</li>
					</ul>
					<li>Only use HTTPS when necessary</li>
					<ul>
						<li>HTTPS is end-to-end encrypted and bypasses some caches</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Client Caching</title>
			<slide>
				<title>Caching Conformance</title>
				<ul>
					<li>Caching is optional and HTTP implementations may not cache at all</li>
					<ul>
						<li>caching eliminates some requests entirely</li>
						<li>caching allows responses to be more effective (<http>304 Not Modified</http>)</li>
					</ul>
					<li>Implementations that support caching must follow the rules</li>
					<ul>
						<li>any cached local resource must always use the latest version</li>
						<li>if HTTP metadata expires that version it should not be used</li>
						<li>servers can mark resources to disallow the use of stale versions</li>
					</ul>
					<li>HTTP allows explicit and heuristic expiration</li>
					<ul>
						<li>not all resources are explicitly marked with expiration dates</li>
						<li>caches are allowed to guess expiration dates (e.g., using <http>Last-Modified</http>)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Mobile Safari Caching</title>
				<ul>
					<li>Mobile Safari <a href="http://www.phpied.com/iphone-caching/">does a bad job at caching</a></li>
					<ul>
						<li>caching behavior is not documented and cannot be changed</li>
						<li>the mobile browsing experience is substantially degraded</li>
					</ul>
					<li>It seems that caching is <link href="constraints">based on the platform's minimal RAM</link></li>
					<ul>
						<li>nothing bigger than 15KB is cached (some sources say the limit is 25KB)</li>
						<li>total cache size is 1.5MB (very likely caused by RAM-only caching)</li>
						<li>there seems to be no persistent cache (no storage outside of RAM)</li>
					</ul>
					<li><link href="appcache">AppCache</link> can be used to <q>improve</q> caching</li>
					<ul>
						<li>risky strategy because it may have unintended side-effects</li>
						<li>inconvenient because everything must be <q>packaged</q> as an <q>application</q></li>
						<li>incomplete because this only works for HTML5 implementations (no proxy support)</li>
						<li>clients may start treating AppCache differently if it becomes (too) widely-used</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Native Application Caching</title>
				<ul>
					<li>Caching is important for almost any network activity</li>
					<ul>
						<li>Web-based applications by definition primarily use HTTP communications</li>
						<li>native applications in most cases also use HTTP communications</li>
						<li>instead of implementing HTTP they typically use HTTP libraries</li>
					</ul>
					<li><code href="http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/Reference/Reference.html">NSURLRequest</code> is the iPhone OS API for requesting URIs</li>
					<ul>
						<li><code href="http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/Reference/Reference.html#//apple_ref/doc/uid/20001695-DontLinkElementID_1">NSURLRequestCachePolicy</code> allows to set the cache policy for a request</li>
						<li>HTTP headers are set based on the selected request policy</li>
					</ul>
					<li>How is the caching architecture of the iPhone library?</li>
					<ul>
						<li>caching is only done in RAM (i.e., there is no persistent cache)</li>
						<li>caching is done on a per-process base (i.e., there is no shared cache)</li>
					</ul>
					<li>Mobile platforms seem to not support HTTP very well</li>
					<ul>
						<li>caching has to be implemented in the application (<link href="flickr-iphone">Flickr app</link>)</li>
						<li>it could be made reusable (Facebook app and <a href="http://github.com/facebook/three20/">three20</a>)</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Server Configuration for Caching</title>
			<slide>
				<title>More Metadata is Better</title>
				<ul>
					<li>HTTP supports a comprehensive set of metadata fields</li>
					<ul>
						<li>more metadata can be used to support better caching</li>
					</ul>
					<li>Tuning caching is important but non-trivial and application-specific</li>
					<ul>
						<li>requires knowledge about what can/will change and when</li>
						<li>HTTP servers should automate/support as much as possible</li>
					</ul>
					<li>HTTP servers support more advanced interactions with clients</li>
					<ul>
						<li>clients can advertise compression support with <http>Accept-Encoding</http></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Freshness of Responses</title>
				<ul>
					<li><http>Expires</http> tells a cache how long data is fresh</li>
					<ul>
						<li>defined by HTTP/1.0 and easy to use and support</li>
						<li>caches will typically simply reuse data before the expiration date</li>
						<li>caches have to check for changes after the expiration date</li>
					</ul>
					<li><http>Cache-Control</http> supports a more nuanced caching model</li>
					<ul>
						<li>introduced in HTTP/1.1 to address <http>Expires</http> limitations</li>
						<li>expiration dates can now be made relative</li>
						<li>support for caching and control of authenticated content</li>
					</ul>
					<li>Caching support should set the right headers</li>
					<ul>
						<li>Apache supports caching and uses both headers</li>
						<li>caching only works when validators are present</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Configuration Steps</title>
				<ul>
					<li>Configure the server to support setting expiration dates</li>
					<listing src="httpd.conf" line="97"/>
					<li>Configure the setting of dates for a specific directory</li>
					<listing src="./src/caching/.htaccess" line="1-1"/>
					<li>Configure how dates should be set for certain types</li>
					<listing src="./src/caching/.htaccess" line="3-10"/>
					<li>Content will now be served <a href="src/caching/">with the appropriate headers</a></li>
					<li>Apache's <code href="http://httpd.apache.org/docs/2.2/mod/mod_expires.html">mod_expires</code> supports a wide variety of settings</li>
				</ul>
			</slide>
			<slide id="etag">
				<title short="ETags">Entity Tags (Etags)</title>
				<ul>
					<li>Timestamps are weak identifiers for caching</li>
					<ul>
						<li>timestamps may change even if nothing changed</li>
					</ul>
					<li><code title="Entity Tag">ETag</code> is a server-assigned identifier for a response entity</li>
					<ul>
						<li>caches store ETags alongside the actual representation</li>
						<li>when validating content clients/caches include the ETag</li>
					</ul>
					<li>What is the relationship between URIs and ETags?</li>
					<ul>
						<li>URIs identify abstract resources that can be accessed via the Web</li>
						<li>ETags identify a concrete version of such a resource</li>
						<li>ETags change when <q>something relevant</q> happens to the resource</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>The Problem with ETags</title>
				<ul>
					<li>ETags are meant to be unique tags for one version</li>
					<ul>
						<li>CMS-based servers can use IDs generated from the CMS</li>
						<li>file-based servers have to generate unique identifiers</li>
					</ul>
					<li>File-based content often uses rule-based ETags</li>
					<ul>
						<li>Apache uses <q><code>inode-size-timestamp</code></q> as the value of the ETag</li>
						<li>such an ETag depends on the actual file system (not just the file itself)</li>
						<pre>FileETag INode MTime Size</pre>
					</ul>
					<li>Server farms often use load balancers and replicated files</li>
					<ul>
						<li>file replication will produce different <code>inode</code> values</li>
						<li>ETag-based caching in such a scenario is server-specific</li>
						<li>the files are <em>equal</em> but not <em>identical</em></li>
					</ul>
					<li>ETags should be configured as <q>correctly</q> as possible</li>
					<pre>FileETag MTime Size</pre>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="adaptation">
		<title>Content Adaptation</title>
		<date>2010-04-19</date>
		<toc class="reading"><a href="http://proquest.safaribooksonline.com/9780596806231/adapting_to_devices" title="Mobile Design and Development; Chapter 13: Adapting to Devices">Adapting to Devices</a></toc>
		<toc class="resources"><a href="http://en.wikipedia.org/wiki/.mobi" title="Wikipedia: .mobi"><code>.mobi</code></a>&#160;· <a href="http://wurfl.sourceforge.net/" title="Wireless Universal Resource File">WURFL</a></toc>
		<toc class="abstract">Mobile applications need to address the diversity of clients, and can do so in a variety of ways. In this lecture, we take a brief look at how to implement client-side adaptation, which uses client-side mechanisms (HTML and scripting) to adapt to the capabilities of the client. We also look at server-side mechanisms such as HTTP content negotiation, and at various ways in which mobile-specific content can be published on the web.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Compressing Resources</title>
			<slide>
				<title>Displaying Request Headers</title>
				<img src="cylog-headers.png" href="http://www.cylog.org/headers/" style="float : right ; width : 30% ; margin-top : 0.5em ; margin-right : 2em ; "/>
				<table>
					<tr>
					  <td valign="top"><code>host</code></td>
					  <td valign="top">www.cylog.org</td>
					</tr>
					<tr>
					  <td valign="top"><code>user-agent</code></td>
					  <td valign="top">Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)</td>
					</tr>
					<tr>
					  <td valign="top"><code>accept</code></td>
					  <td valign="top">text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8</td>
					</tr>
					<tr>
					  <td valign="top"><code>accept-language</code></td>
					  <td valign="top">en-us,en;q=0.7,de-de;q=0.3</td>
					</tr>
					<tr>
					  <td valign="top"><code>accept-encoding</code></td>
					  <td valign="top">gzip,deflate</td>
					</tr>
					<tr>
					  <td valign="top"><code>accept-charset</code></td>
					  <td valign="top">ISO-8859-1,utf-8;q=0.7,*;q=0.7</td>
					</tr>
					<tr>
					  <td valign="top"><code>Keep-Alive</code></td>
					  <td valign="top">115</td>
					</tr>
					<tr>
					  <td valign="top"><code>connection</code></td>
					  <td valign="top">keep-alive</td>
					</tr>
					<tr>
					  <td valign="top"><code>referer</code></td>
					  <td valign="top">http://www.google.com/search?q=http+header+display&amp;ie=utf-8&amp;oe=utf-8&amp;aq=t&amp;rls=org.mozilla:en-US:official&amp;client=firefox-a</td>
					</tr>
					<tr>
					  <td valign="top"><code>content-length</code></td>
					  <td valign="top">0</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>Displaying Response Headers</title>
				<ul>
					<li><a href="http://www.rexswain.com/httpview.html">Web-based HTTP clients</a> allow HTTP response header display</li>
					<li>Sending request…</li>
					<pre>GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Referer: http://www.rexswain.com/httpview.html
Connection: close</pre>
					<li>Receiving header…</li>
					<pre>HTTP/1.1 200 OK
Date: Mon, 19 Apr 2010 16:43:41 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=c28e991dec69844c:TM=1271695421:LM=1271695421:S=ubsNGUpXiUn3I2mg; expires=Wed, 18-Apr-2012 16:43:41 GMT; path=/; domain=.google.com
Set-Cookie: NID=33=YSu8-UTI70uOYYVs4Q1AlCK017SE_w6nL_3ApNfs_mM_FdGs6-plZ2IsxR6awHC8Gssg49FxWC-uOpdMJv1PmEiKYq0YEkMeJn79DQd6SdjTfjwrcfwyL3FHSYHwRMKW; expires=Tue, 19-Oct-2010 16:43:41 GMT; path=/; domain=.google.com; HttpOnly
Server: gws
Connection: close</pre>
					<li>Receiving content…</li>
					<pre>&lt;!doctype html>&lt;html</pre>
				</ul>
			</slide>
			<slide>
				<title>HTTP Compression</title>
				<ul>
					<li>Web data formats vary widely in compression</li>
					<ul>
						<li>media formats (GIF, PNG, JPEG) already use advanced compression methods</li>
						<li>source formats (HTML, CSS, JavaScript) has a lot of redundancy</li>
					</ul>
					<li>Some formats have well-established methods for <q>compression</q></li>
					<ul>
						<li><em>minification</em> removes all redundant information from HTML/CSS/JavaScript</li>
						<li><em>obfuscation</em> even rewrites the non-redundant parts for compactness</li>
					</ul>
					<li>HTTP supports the idea of <em href="http://tools.ietf.org/html/rfc2616#section-3.6">transfer encodings</em></li>
					<ul>
						<li>clients can advertise their support with <http>Accept-Encoding</http></li>
						<li>servers can serve content with a supported <http>Transfer-Encoding</http></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Configuring HTTP Compression</title>
				<ul>
					<li>Configure the server to support compression</li>
					<listing src="httpd.conf" line="93"/>
					<li>Configure support of HTTP compression for certain types</li>
					<listing src="./src/caching/.htaccess" line="12-13"/>
					<li>HTML content will now be served <a href="src/caching/">in compressed form</a></li>
					<li>Apache's <code href="http://httpd.apache.org/docs/2.2/mod/mod_deflate.html">mod_deflate</code> supports a wide variety of settings</li>
				</ul>
			</slide>
		</part>
		<part id="client-side-adaptation">
			<title>Client-Side Approaches</title>
			<slide>
				<title>Graceful Degradation</title>
				<ul>
					<li>HTML's basic idea is to allow graceful degradation</li>
					<ul>
						<li>clients not supporting advanced features should still work</li>
						<li>anything that does not gracefully degrade compromises accessibility</li>
						<li><em>Flash</em> is the poster child for non-graceful degradation</li>
					</ul>
					<li>HTML/CSS is the best example for graceful degradation</li>
					<ul>
						<li>partial or even no CSS support does not change the basic rendering</li>
						<li>graceful degradation becomes hard beyond a certain level of complexity</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>DIY Degradation</title>
				<listing src="waiting.html"/>
			</slide>
		</part>
		<part id="server-side-adaptation">
			<title>Server-Side Approaches</title>
			<slide>
				<title>Serving Different Content</title>
				<ul>
					<li>Servers often serve different content</li>
					<ul>
						<li>requests are sent by clients</li>
						<li>requests can be inspected or generated in a client-specific way</li>
						<li>server-side logic can be used to specifically process requests</li>
					</ul>
					<li>Server-Side approaches can be hard to maintain and extend</li>
					<ul>
						<li>how to integrate new content into the existing service</li>
						<li>how to deal with new clients/devices when they appear</li>
					</ul>
					<li>All approaches need some robust idea of <q>buckets</q></li>
					<ul>
						<li>individual client types are sorted into buckets</li>
						<li>new client types most often are sorted into an existing bucket</li>
						<li>adding a new bucket is expensive and should be done rarely</li>
					</ul>
				</ul>
			</slide>
			<part id="conneg">
				<title short="Content Negotiation">HTTP Content Negotiation</title>
				<slide>
					<title>Inspecting Client Requests</title>
					<ul>
						<li>Clients disclose their <q>type</q> in the <http>User-Agent</http> header field</li>
						<pre>Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10</pre>
						<pre>Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3</pre>
						<li>Servers can send content based on HTTP or sniffing info</li>
					</ul>
				</slide>
			</part>
			<part>
				<title>Multiple URI Spaces</title>
			<slide>
				<title>Mobile Naming Variations</title>
				<ul>
					<li>URIs can be used in a number of different ways</li>
					<ul>
						<li>any Web-based publishing should have a strategy for using URIs</li>
						<li>being consistent is almost as important as doing it right</li>
					</ul>
					<li>For variations of URIs, various parts of the Web architecture can be used</li>
					<ul>
						<li>DNS names for naming servers</li>
						<li>various parts of the URI name</li>
						<li>protocol mechanisms of HTTP or <link href="cookies"/></li>
					</ul>
					<li>This problem is similar to <a href="../web-fall09/i18n+l10n#i18n-uri">multilingual pages</a></li>
					<ul>
						<li>handling both problems in a consistent way is important</li>
						<li>organizational issues can be more important than architectural purity</li>
					</ul>
				</ul>
			</slide>
				<slide>
					<title>Subdomains for Mobile Pages</title>
					<pre>http://<span style="color : red">m.</span>example.com/some/page</pre>
					<ul>
						<li>Defines DNS subdomains for mobile pages</li>
						<li>Advantages</li>
						<ul>
							<li>offers easy load-balancing to different servers (but code must kept in sync)</li>
							<li>bookmarks identify the mobile variant</li>
						</ul>
						<li>Disadvantages</li>
						<ul>
							<li>no easy way to get from one variant to another in terms of <q>URI navigation</q></li>
							<li>scheme requires DNS updates and management</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title><code>.mobi</code> for Mobile Pages</title>
					<pre>http://example<span style="color : red">.mobi</span>/some/page</pre>
					<ul>
						<li>Use the <code>mobi</code> DNS TLD to identify the mobile page</li>
						<li>Advantages</li>
						<ul>
							<li>bookmarks identify the mobile variant</li>
						</ul>
						<li>Disadvantages</li>
						<ul>
							<li>requires registration of additional DNS entry (effort, costs, domain squatting)</li>
							<li>managing two DNS spaces can become challenging</li>
							<li>what if there is more than one mobile variant?</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>URI Paths for Mobile Pages</title>
					<pre>http://example.com/<span style="color : red">mobile/</span>some/page</pre>
					<ul>
						<li>Encodes <q>mobile</q> as the first path segment of the URI path</li>
						<li>Advantages</li>
						<ul>
							<li>bookmarks identify the mobile variant</li>
						</ul>
						<li>Disadvantages</li>
						<ul>
							<li>logically, the URI path does not represent the hierarchy of resources</li>
							<li>no easy way to get from one variant to another in terms of <q>URI navigation</q></li>
							<li>hard to maintain if this is used as the actual layout of documents in directories</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>Final Project Planning</title>
			<slide>
				<title>Project Development</title>
				<ul>
					<li>Timeline:</li>
					<ul>
						<li>projects assigned this week</li>
						<li>lecture time as lab time plus lab times next week</li>
						<li>HTML mockups dues for presentation 5/3 and 5/5</li>
						<li>final project due 5/14 (submission of report, code, and phone)</li>
					</ul>
					<li>Your proposal is your deliverable</li>
					<ul>
						<li>but we have to make sure you have well-defined and achievable goals</li>
						<li>doing several smaller steps is better than doing one big step</li>
						<li>we will ask for reports and code for all projects</li>
						<li>the minimal code part is the HTML code due at project halftime</li>
						<li><em>design projects</em> need to include a complete UI/UX description</li>
						<li><em>implementation projects</em> need to to include some functioning code</li>
					</ul>
					<li>Try to cleanly separate the vision from the tasks</li>
					<ul>
						<li>your final project report/code should demonstrate a part of the solution</li>
						<li>submit partial code instead of submitting dysfunctional code</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="maria" external="skimble.pdf">
		<title short="Skimble">Designing and Developing Mobile Tools for the Active Market</title>
		<date>2010-04-21</date>
		<toc class="author">Maria Ly</toc>
		<toc class="resources"><a href="http://www.skimble.com/">Skimble</a> (<a href="http://itunes.com/skimble">iPhone</a>|<a href="http://www.skimble.com/switch_ui?ui=mobile">mobile</a>)&#160;· <a href="http://github.com/facebook/three20">three20</a>&#160;· <a href="http://www.amazon.com/HTML5-Now-Step-Step-Tutorial/dp/0321719913" title='"HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today" by Tantek Çelik'>HTML5 Now</a></toc>
		<toc class="abstract">Skimble's case study of how we developed our activity tracking and sharing tools for people on-the-go. Learn about the trials and tribulations we experienced from Skimble's conception stage all the way to launching our first application in the iTunes App Store.</toc>
	</presentation>
	<presentation id="kiyo" external="spotlight.pdf">
		<title short="Spotlight Mobile">TBD</title>
		<date>2010-04-23</date>
		<toc class="author">Kiyo Kubo</toc>
		<toc class="resources"><a href="http://www.spotlightmobile.com/">Spotlight Mobile</a></toc>
		<toc class="abstract">Kiyo Kubo is CEO of <a href="http://www.spotlightmobile.com/">Spotlight Mobile</a>.</toc>
	</presentation>
</hotspot>
