<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Jeremy Madea</title>
	<atom:link href="http://www.madea.net/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.madea.net</link>
	<description>Systems Architect &#38; Consultant</description>
	<lastBuildDate>Tue, 31 Jan 2012 17:13:19 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>A Robustness Corollary</title>
		<link>http://www.madea.net/2012/01/31/a-robustness-corollary/</link>
		<comments>http://www.madea.net/2012/01/31/a-robustness-corollary/#comments</comments>
		<pubDate>Tue, 31 Jan 2012 17:10:43 +0000</pubDate>
		<dc:creator>jeremy</dc:creator>
				<category><![CDATA[Tech]]></category>
		<category><![CDATA[browsers]]></category>
		<category><![CDATA[HTTP]]></category>
		<category><![CDATA[standards]]></category>

		<guid isPermaLink="false">http://www.madea.net/?p=34</guid>
		<description><![CDATA[You&#8217;re probably familiar with the robustness principle which is usually stated as: Be liberal in what you accept, and conservative in what you send. When it comes to standards, I&#8217;d like to offer a corollary: Be precise in your description and flexible in your interpretation.  &#160; An example of where this corollary could be applied is [...]]]></description>
			<content:encoded><![CDATA[<p>You&#8217;re probably familiar with the <a title="Robustness Principle" href="http://en.wikipedia.org/wiki/Robustness_principle" target="_blank">robustness principle</a> which is usually stated as:</p>
<blockquote><p><em>Be liberal in what you accept, and conservative in what you send.</em></p></blockquote>
<p>When it comes to standards, I&#8217;d like to offer a corollary:</p>
<p style="padding-left: 30px;"><strong>Be precise in your description and flexible in your interpretation. </strong></p>
<p>&nbsp;</p>
<p>An example of where this corollary could be applied is in some browser developers&#8217; handling of HTTP&#8217;s 301 &#8220;Moved Permanently&#8221; responses. According to   RFC 2616, section 10.3.2 &#8220;301 Moved Permanently&#8221;:</p>
<blockquote><p>The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.</p></blockquote>
<p>That&#8217;s all well and good but permanence is an elusive thing on the web. Websites and applications tend to change quite a lot, especially during development. And when aren&#8217;t they under development? Even if mistakes were never made, the ownership of domains (and therefore URIs) is subject to change.</p>
<p>None of that would pose a problem in this instance if it weren&#8217;t for browser developers who cache 301 responses for a resource indefinitely and use one of the returned URIs for all future references to that resource.</p>
<p>But, but, but! . . . That&#8217;s what the RFC says they SHOULD do, right? And isn&#8217;t a good thing that they want to be called &#8220;unconditionally compliant?&#8221;</p>
<p>Yes. But that misses the point. The phrase &#8220;<em>any future references to this resource</em>&#8221; can be quite flexibly interpreted. Any future references handled by what exactly? Some browser developers have decided it should mean any future references handled by an <em>installation</em> of their browser. It would be a lot more reasonable, especially from the perspective of web developers, if the browser developers simply interpreted it to mean an <em>instance</em> instead, at least, in the absence of specific caching instructions.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.madea.net/2012/01/31/a-robustness-corollary/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Feeble Visions</title>
		<link>http://www.madea.net/2012/01/18/feebl-visions/</link>
		<comments>http://www.madea.net/2012/01/18/feebl-visions/#comments</comments>
		<pubDate>Wed, 18 Jan 2012 20:01:51 +0000</pubDate>
		<dc:creator>jeremy</dc:creator>
				<category><![CDATA[Tech]]></category>
		<category><![CDATA[computing]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[future]]></category>
		<category><![CDATA[interaction]]></category>
		<category><![CDATA[rant]]></category>
		<category><![CDATA[tech]]></category>

		<guid isPermaLink="false">http://www.madea.net/?p=25</guid>
		<description><![CDATA[Here is an awesome rant on the feeble vision some big players have for the future of interaction design. The author, Bret Victor, a onetime &#8220;human interface inventor&#8221; at Apple, complains that the vision of the future where we are sliding around &#8220;pictures behind glass&#8221; isn&#8217;t really visionary but just a tiny step from where we are [...]]]></description>
			<content:encoded><![CDATA[<p>Here is <a title="A Brief Rant on the Future of Interaction Design" href="http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/" target="_blank">an awesome rant</a> on the feeble vision some big players have for the future of interaction design.</p>
<p>The author, Bret Victor, a onetime &#8220;human interface inventor&#8221; at Apple, complains that the vision of the future where we are sliding around &#8220;pictures behind glass&#8221; isn&#8217;t really <em>visionary</em> but just a tiny step from where we are now.</p>
<p>I&#8217;m inclined to agree.</p>
<p>Moreover, I think this vision isn&#8217;t just limited; it&#8217;s limit<em>ing</em> too. If we can&#8217;t conceive of richer ways to interact with our computers, we&#8217;ll be restricting our ability to see what problems we can solve with them.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.madea.net/2012/01/18/feebl-visions/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

