<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="/topics-files/atom2xhtml.xsl" type="text/xsl"?>
<!-- This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers. -->
<feed xmlns="http://www.w3.org/2005/Atom"
><title
>Blog@Case Topics: http</title
><link rel="self" href="http://blog.case.edu/topics/http"
 /><id
>http://blog.case.edu/topics/http</id
><category term="http" label="http"
 /><link rel="related" href="http://blog.case.edu/topics/web%20services" title="web services"
 /><link rel="related" href="http://blog.case.edu/topics/mainblog" title="mainblog"
 /><link rel="related" href="http://blog.case.edu/topics/linkblog" title="linkblog"
 /><link rel="related" href="http://blog.case.edu/topics/programming" title="programming"
 /><link rel="related" href="http://blog.case.edu/topics/general%20information%20technology" title="general information technology"
 /><link rel="related" href="http://blog.case.edu/topics/weblog%20tech" title="weblog tech"
 /><link rel="related" href="http://blog.case.edu/topics/cms" title="cms"
 /><link rel="related" href="http://blog.case.edu/topics/blog@case%20developments" title="blog@case developments"
 /><link rel="related" href="http://blog.case.edu/topics/failures%20of%20technology" title="failures of technology"
 /><link rel="related" href="http://blog.case.edu/topics/ldap" title="ldap"
 /><link rel="related" href="http://blog.case.edu/topics/federated%20identity" title="federated identity"
 /><contributor
><name
>Gregory Szorc</name
><email
>gregory.szorc@case.edu</email
><uri
>http://blog.case.edu/gps10</uri
></contributor
><contributor
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></contributor
><updated
>2007-10-25T19:27:19Z</updated
><entry
><title
>Architecting URLs</title
><link href="http://blog.case.edu/jeremy.smith/2007/10/25/architecting_urls"
 /><id
>http://blog.case.edu/jeremy.smith/2007/10/25/architecting_urls</id
><published
>2007-10-25T19:23:59Z</published
><updated
>2007-10-25T19:27:19Z</updated
><category term="HTTP" label="HTTP"
 /><category term="information architecture" label="information architecture"
 /><category term="linkblog" label="linkblog"
 /><category term="web" label="web"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="URLs suck - jerakeen.org" href="http://jerakeen.org/blog/2007/08/06/urls-suck/">URLs suck</a> I've faced the same dilemma.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>PHP Now Using Proper HTTP Status Codes on Error</title
><link href="http://blog.case.edu/gps10/2007/08/23/php_now_using_proper_http_status_codes_on_error"
 /><id
>http://blog.case.edu/gps10/2007/08/23/php_now_using_proper_http_status_codes_on_error</id
><published
>2007-08-23T08:39:24Z</published
><updated
>2007-08-23T09:03:15Z</updated
><category term="HTTP" label="HTTP"
 /><category term="PHP" label="PHP"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>I'm not sure if I have blogged about this before, but one of my biggest complaints about PHP is how it dies. If it encounters a serious error, like a parse error, it just stops and there is nothing you can do about it. If this happens on a hosted web site, you get a blank page served with the HTTP status code of 200. Completely useless to remote connections. Marginally useful is the PHP error logging to isolate the problem, but even then... I was glancing through the upcoming 
<a href="http://cvs.php.net/viewvc.cgi/php-src/NEWS?revision=PHP_5_2">PHP 5.2.4 changes</a> and saw this:
<blockquote>Changed error handler to send HTTP 500 instead of blank page on PHP errors. (Dmitry, Andrei Nigmatulin)</blockquote>Proper HTTP status code usage! To someone who loves utilizing HTTP to its fullest, this is wonderful news! Although I haven't seen documentation for this new "feature", I assume this means that I can finally guarantee that if my web service emits a 200 status code, the response is well-defined. I hope so, or my griping will persist...</div
></content
><author
><name
>Gregory Szorc</name
><email
>gregory.szorc@case.edu</email
><uri
>http://blog.case.edu/gps10</uri
></author
></entry
><entry
><title
>OpenID Server Integrated with CAS</title
><link href="http://blog.case.edu/jeremy.smith/2007/03/09/openid_server_integrated_with_cas"
 /><id
>http://blog.case.edu/jeremy.smith/2007/03/09/openid_server_integrated_with_cas</id
><published
>2007-03-10T00:53:01Z</published
><updated
>2007-03-10T00:55:54Z</updated
><category term="Federated Identity" label="Federated Identity"
 /><category term="HTTP" label="HTTP"
 /><category term="Programming" label="Programming"
 /><category term="Shibboleth" label="Shibboleth"
 /><category term="Web Services" label="Web Services"
 /><category term="cas" label="cas"
 /><category term="identity management" label="identity management"
 /><category term="mainblog" label="mainblog"
 /><category term="openid" label="openid"
 /><category term="web" label="web"
 /><category term="web standards" label="web standards"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>With the help of some of the Network Engineers (to get some magic routing working), I cobbled together an 
<a title="OpenID: an actually distributed identity system" href="http://openid.net/">OpenID</a> server and integrated it with 
<a href="http://www.case.edu">Case's</a> 
<a title="Case Central Authentication Service (CAS)" href="https://login.case.edu">Single Sign On</a> system, 
<a title="Central Authentication Service - CaseWiki" href="http://wiki.case.edu/Central_Authentication_Service">CAS</a>. The "server" end-point is located at 
<a href="http://login.case.edu/id">http://login.case.edu/id</a>. Your "identity URL" is the 
<em>first.last</em> portion of your email address followed with 
<strong>.id.case.edu</strong>. For example, my email is 
<a href="mailto:jeremy.smith@case.edu">jeremy.smith@case.edu</a>, so my OpenID identity URL is 
<a href="http://jeremy.smith.id.case.edu">
<strong>jeremy.smith.id.case.edu</strong>
</a>. For those averse to typing (like I am), you can also use your 
<a title="Case Network ID - CaseWiki" href="http://wiki.case.edu/Case_Network_ID">Case Network ID</a> followed by 
<strong>.id.case.edu</strong>. So, I could also use 
<a href="http://jms18.id.case.edu">
<strong>jms18.id.case.edu</strong>
</a>. If you want to try logging in with it, you can head over to 
<a title="Simon Willison's Weblog" href="http://simonwillison.net/">Simon Willison's Weblog</a> and, at the top where it says "Sign in with OpenID," click on that and enter 
<strong>&lt;USERNAME&gt;.id.case.edu</strong>. A better example is logging into 
<a title="Free Worldwide Travel Guides - Wikitravel" href="http://wikitravel.org/">Wikitravel</a> because it shows how information (such as nicknames, email address, full name, etc.) can be shared between a OpenID Provider and client. You can sign in to Wikitravel 
<a title="Login with OpenID - Wikitravel" href="http://wikitravel.org/en/Special:OpenIDLogin">here</a>. The information sharing part doesn't so much "work" yet. I'm getting there. And because it is integrated upwards towards 
<a href="http://wiki.case.edu/CAS">CAS</a>, it should interoperate with all of the other "identity systems/protocols" we've integrated with CAS like 
<a title="Shibboleth Project - Internet2 Middleware" href="http://shibboleth.internet2.edu/">Shibboleth</a> (and, in testing, Oracle's Single Sign On, Sun's, and 
<a title="Google Apps - SAML-based Single Sign-On" href="http://code.google.com/apis/apps/sso/saml_reference_implementation.html">Google's SAML-based Single Sign-On</a>). I may throw up some screencasts showing the effects of this by bouncing in between normal CAS-protected apps (like this 
<a href="http://blog.case.edu">blog system</a> or the 
<a href="http://wiki.case.edu">wiki</a>), Shibboleth protected ones, and OpenID protected ones.</div
></content
><author
><name
></name
><email
>blog-admin@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Web Application Performance and Scalability</title
><link href="http://blog.case.edu/gps10/2007/02/25/web_application_performance_and_scalability"
 /><id
>http://blog.case.edu/gps10/2007/02/25/web_application_performance_and_scalability</id
><published
>2007-02-25T20:00:00Z</published
><updated
>2007-02-25T21:10:25Z</updated
><category term="HTTP" label="HTTP"
 /><category term="optimization" label="optimization"
 /><category term="scaling" label="scaling"
 /><category term="web services" label="web services"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>If you frequent community-driven news sites such as 
<a href="http://www.digg.com">Digg</a> and 
<a href="http://www.reddit.com">Reddit</a>, you often come across posts on how to get every drop of performance out of your web application. The sister issue of scalability is oftentimes addressed, usually in its manifestation, loss of service due to overwhelming usage. These performance-enhancing and scalability guides often focus on software-level solutions. Use this data type. Use that API or framework. Use caching in your application-- and here is how to implement it in Perl/Ruby/PHP/Java/.NET. There is always the tip on how to make a simple caching framework in your favorite web application language. There is always the list of settings to tune your web server and your script execution engine. These are all fine and dandy, but people always seem to overlook the obvious solution. Most web applications generate the same set of data for sequential requests, even highly-dynamic, user-driven, Web 2.0 sites. With this in mind, we realize that all web applications share the simple trait that they communicate using the HTTP protocol. There is a server. There is a client. In between there is HTTP. Nothing more. Nothing less. And wouldn't you know it, the 
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">HTTP specification</a> has a 
<a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">whole section</a> on caching! So, next time you are trying to squeeze hits per second out of your web application, don't search the net for obscure hacks and optimizations, turn to the specs. Introducing a few extra HTTP headers into your dynamically-generated response and adding a web cache, such as 
<a href="http://www.squid-cache.org/">Squid</a>, in front of your main web server will do more than you realize. Even if you implement caching inside of your web script, you still have to go through all the overhead to initialize the script for each request. In many cases, the functionality of your page output cache can be duplicated using HTTP caching. It makes no sense to execute a script for a simple HTTP GET request. In the ideal world, the only time a request should actually hit your script server is when new data is being sent or when the HTTP cache does not have the data you seek. Now that you have been enlightened, your challenge is to implement it. I admit, it can be challenging, especially when content on your site is highly dynamic. But just think of the smile on your face when you realize you just increased capacity by a factor of ten without buying new hardware. Never underestimate the power of the HTTP protocol.</div
></content
><author
><name
>Gregory Szorc</name
><email
>gregory.szorc@case.edu</email
><uri
>http://blog.case.edu/gps10</uri
></author
></entry
><entry
><title
>Sucky URLs</title
><link href="http://blog.case.edu/jeremy.smith/2007/01/18/sucky_urls"
 /><id
>http://blog.case.edu/jeremy.smith/2007/01/18/sucky_urls</id
><published
>2007-01-18T07:11:03Z</published
><updated
>2007-01-18T07:10:08Z</updated
><category term="General Information Technology" label="General Information Technology"
 /><category term="HTTP" label="HTTP"
 /><category term="information architecture" label="information architecture"
 /><category term="linkblog" label="linkblog"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="The Well Designed URLs Initiative Blog &#239;&#191;&#189; Blog Archive &#239;&#191;&#189; Help Expose the URLs that Suck!" href="http://blog.welldesignedurls.org/2007/01/17/expose-urls-that-suck/">Help Expose the URLs that Suck!</a>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Web APIs Are Just Web Sites</title
><link href="http://blog.case.edu/jeremy.smith/2007/01/16/web_apis_are_just_web_sites"
 /><id
>http://blog.case.edu/jeremy.smith/2007/01/16/web_apis_are_just_web_sites</id
><published
>2007-01-16T17:41:13Z</published
><updated
>2007-01-16T17:41:29Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="linkblog" label="linkblog"
 /><category term="web" label="web"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="Paul Downey &#239;&#191;&#189; Blog Archive &#239;&#191;&#189; Web APIs Are Just Web Sites" href="http://blog.whatfettle.com/2007/01/11/good-web-apis-are-just-web-sites/">Web APIs Are Just Web Sites</a> Nobody believes me when I tell them that.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Some Technical Notes on Google's Mobile Services</title
><link href="http://blog.case.edu/jeremy.smith/2006/12/11/google_mobile"
 /><id
>http://blog.case.edu/jeremy.smith/2006/12/11/google_mobile</id
><published
>2006-12-11T22:17:41Z</published
><updated
>2006-12-11T22:16:42Z</updated
><category term="HTTP" label="HTTP"
 /><category term="css" label="css"
 /><category term="html" label="html"
 /><category term="mainblog" label="mainblog"
 /><category term="semantic web" label="semantic web"
 /><category term="web" label="web"
 /><category term="web standards" label="web standards"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>Mental notes (serialized to blog) to myself concerning 
<a title="Jeremy Smith's blog: Delivering Web Content to Mobile Devices" href="http://blog.case.edu/jms18/2006/11/13/delivering_web_content_to_mobile_devices">delivering web content to handhelds</a> and in regards to how 
<a href="http://google.com">Google</a> does it currently. 
<a title="Google" href="http://mobile.google.com/local">Google Mobile Search</a>, 
<a href="http://m.gmail.com/">Mobile GMail</a>, and 
<a href="http://mobile.google.com/news?output=xhtml&amp;hl=en">Mobile News</a> all use 
<a title="XHTML Mobile Profile - Wikipedia, the free encyclopedia" href="http://en.wikipedia.org/wiki/XHTML_Mobile_Profile">XHTML-MP</a> with CSS delivered inline or in the 
<code>&lt;head&gt;</code> section with 
<code>&lt;style type="text/css"&gt;</code> sections. They do a lot of sprinkling of presentational HTML in there, too. One interesting note. Mobile search is delivered with 
<code>Content-type</code> set to 
<code>text/html</code>. Mobile GMail and Mobile News are delivered as 
<code>application/xhtml+xml</code>. The Mobile Maps stuff require a phone with a JRE on it and you must download an app to your phone.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>SOAP v. Rest</title
><link href="http://blog.case.edu/jeremy.smith/2006/11/17/soap_v_rest"
 /><id
>http://blog.case.edu/jeremy.smith/2006/11/17/soap_v_rest</id
><published
>2006-11-17T08:01:59Z</published
><updated
>2006-11-17T18:47:26Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="linkblog" label="linkblog"
 /><category term="rest" label="rest"
 /><category term="web standards" label="web standards"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>Because I can't help but link to SOAP/REST discussions: 
<a title="Pete Lacey&#226;&#8364;&#8482;s Weblog :: The S stands for Simple" href="http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/">The S stands for Simple</a> 
<a title="Getting Data | The REST Dialogues | What Not How | http://duncan-cragg.org/blog/" href="http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/">The REST Dialogues</a> A well reasoned response from the other side: 
<a title="Ian Foster: Web Fundamentalism" href="http://ianfoster.typepad.com/blog/2006/11/the_web_thought.html">Web Fundamentalism</a>. My take... there is a reason CORBA, DCOM, RMI, etc. have failed while the "web" has not, and recreating RMI-"principles" atop HTTP (or SMTP or whatever else) may suffer the same fate. (
<strong>Update:</strong> Sam Ruby has a good post describing some of the 
<a title="Sam Ruby: The H stands for Hyper" href="http://www.intertwingly.net/blog/2006/11/17/The-H-stands-for-Hyper">imperfections encountered</a> with REST style programming (make sure to follow all of his links; they are all worth reading).)</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Delivering Web Content to Mobile Devices</title
><link href="http://blog.case.edu/jeremy.smith/2006/11/13/delivering_web_content_to_mobile_devices"
 /><id
>http://blog.case.edu/jeremy.smith/2006/11/13/delivering_web_content_to_mobile_devices</id
><published
>2006-11-14T01:29:29Z</published
><updated
>2006-11-14T01:35:45Z</updated
><category term="HTTP" label="HTTP"
 /><category term="css" label="css"
 /><category term="html" label="html"
 /><category term="mainblog" label="mainblog"
 /><category term="semantic web" label="semantic web"
 /><category term="web" label="web"
 /><category term="web standards" label="web standards"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>I was doing a "little" reading over the weekend about handheld devices, and I just had to open up this entry with this quote from 
<a title="Are the Groove Designers Architecture Astronauts? - Joel on Software" href="http://www.joelonsoftware.com/articles/fog0000000011.html">Joel Spolsky</a> made over 
<strong>5 years ago</strong>:
<blockquote>If you keep hearing the same examples, you're in deep trouble -- like the idiot WAP people who talk endlessly about how "you'll walk by a starbucks and the GPS in your phone will coordinate to beam you a coupon for that starbucks." I've heard this same example a zillion times from "location based wireless" architecture astronauts and it amuses me, because it solves the one problem that coffee shops DON'T have, namely, advertising to people&#160;
<em>who are standing right in front of the store!</em>&#160;:)</blockquote>Yep, that's a five and a half year old quote, and he seems to have been right because you didn't see any of that take shape over the last half decade. It would be like getting the 
<a href="http://wiki.case.edu/Tomlinson">Tomlinson</a> menu sent to your phone while you were standing in the Tomlinson cafeteria because, ya know, you couldn't 
<em>look up</em> and read it from the big hanging signs on the walls. To continue on, I don't know anything about delivering web content to mobile devices such as Treos, Palms, Blackberries, etc. I knew there were acronyms out there such as "HDML", "C-HTML", "WAP", "WML", maybe some others that I've never heard of. What they did or what they were meant to describe... I didn't know. Wasn't my thing. So over the weekend, I spent some hours (more than I care to admit) reading up on what the Best Practices&#8482; currently are, what's the next Big Thing&#8482; in the area, and what are the points of tension amongst the various groups toiling in this field (these are usually the most interesting and most informative). It turns out, I didn't need to know any of those acronyms. 
<a title="Handheld Device Markup Language - Wikipedia, the free encyclopedia" href="http://en.wikipedia.org/wiki/Handheld_Device_Markup_Language">HDML</a> and 
<a title="C-HTML - Wikipedia, the free encyclopedia" href="http://en.wikipedia.org/wiki/C-HTML">C-HTML</a> were 
<acronym on="">DOA</acronym>. 
<a title="WAP - Wikipedia, the free encyclopedia" href="http://en.wikipedia.org/wiki/WAP">WAP</a> is still kicking around as a 
<a title="OMA Technical Section - Affiliates - Wireless&#239;&#191;&#189;Application&#239;&#191;&#189;Protocol Downloads" href="http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html">v2.0 deal</a> and is helping prop up 
<a title="Wireless Markup Language - Wikipedia, the free encyclopedia" href="http://en.wikipedia.org/wiki/Wireless_Markup_Language">WML</a>. But the 
<a title="W3C Mobile Web Best Practices Working Group" href="http://www.w3.org/2005/MWI/BPWG/">W3C Mobile Web Best Practices Working Group</a> released 
<a title="Mobile Web Best Practices 1.0" href="http://www.w3.org/TR/mobile-bp/">Mobile Web Best Practices 1.0</a> last year, and the recommendation is:
<blockquote>Services should be available as some variant of HTML over HTTP (see 
<a href="http://www.w3.org/TR/mobile-bp/#ddc">3.7 Default Delivery Context</a>).</blockquote>Yep, that's right. Good ol' HTML o'er HTTP. The funny thing is, when I first started researching this, my thoughts were "why are they inventing new markup languages for this?" "Who dropped the ball there?" It got even worse when I found out there was a 
<a title="WMLScript - Wikipedia, the free encyclopedia" href="http://en.wikipedia.org/wiki/WMLScript">WMLScript</a> language and a wCSS vocabulary. "Holy Mother of All Reinventions, Batman!" I thought to myself. Luckily, all of those technologies ended up being in various states of non-start-ness and interoperability amongst devices that implement those standards make IE 5.x on the Mac look easy to develop for. As a matter of fact, WAP 2.0 has been constrained to using HTTP and HTML. From the 
<a title="Terminology - Shared Techniques wiki for the W3C Mobile Web Initative Best Practices" href="http://www.w3.org/2005/MWI/BPWG/techs/Terminology#line-57">W3C Mobile Web Initative Terminology page</a> (emphasis mine):
<blockquote>
<strong>WAP</strong> ... While WAP 1.0 was engineered to work with distinct protocols and the use of WML (Wireless Markup Language) for content markup, 
<strong>WAP 2.0 stipulates end-to-end HTTP and XHTML-MP</strong>, a cut down version of XHTML. This keeps it more in tune with the markup format(s) of the World Wide Web, since WML was a distinct format and content had to be adapted to WML in order to render on devices.</blockquote>The end result it that delivering web content to handhelds is as easy as delivering web content to printers. As long as you started off with clean, semantic HTML and didn't use tables for layout, you specify 
<code>media="handheld"</code> for the CSS rules that should apply when delivering content to "handhelds" a.k.a. mobile devices a.k.a. 
<a title="BlackBerry" href="http://www.blackberry.com/">Blackberries</a> and 
<a title="Palm - Products - Palm&#239;&#191;&#189; Treo 650 Smartphone" href="http://www.palm.com/us/products/smartphones/treo650/">Treos</a>. The article 
<a title="A List Apart: Articles: Pocket-Sized Design: Taking Your Website to the Small Screen" href="http://www.alistapart.com/articles/pocket/">Pocket-Sized Design: Taking Your Website to the Small Screen</a> over on 
<a title="A List Apart: A List Apart" href="http://www.alistapart.com/">A List Apart</a> gives a good description and starting points for designing HTML and CSS for delivery to mobile devices. Two other great resources are 
<a title="W3C Mobile Web Best Practices Working Group - To WML or not" href="http://www.w3.org/blog/BPWG/2005/11/14/to_wml_or_not">To WML or not</a> from the 
<a title="W3C Mobile Web Best Practices Working Group" href="http://www.w3.org/blog/BPWG/">W3C Mobile Web Best Practices Working Group Weblog</a> and the 
<a title="W3C Mobile Web Best Practices checker" href="http://validator.w3.org/mobile/">W3C Mobile Web Best Practices checker</a>. That's it. Just wanted to share with everybody a heaping helping dose(s) of reading material on delivering web content to mobile devices. May it bore you like it did me. (Or you can just choose not to read any of it, which is an entirely reasonable thing to do.)</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>HTTP and Microformats</title
><link href="http://blog.case.edu/jeremy.smith/2006/11/12/http_and_microformats"
 /><id
>http://blog.case.edu/jeremy.smith/2006/11/12/http_and_microformats</id
><published
>2006-11-12T20:19:59Z</published
><updated
>2006-11-12T20:58:33Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="linkblog" label="linkblog"
 /><category term="microformats" label="microformats"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="err.the_blog.find_by_title('Me and uFormats')" href="http://errtheblog.com/post/37">Remember when everyone realized that HTTP was really good at what it did and since we already knew it, we should just use it and stop going crazy with proprietary / complex / lesser known protocols?</a> I think that only like 3% of people have realized that. The other 97% are still using huge "frameworks" and "stacks" to implement something as simple as 
<a title="HTTP/1.1: Status Code Definitions" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5">caching</a> 
<a title="HTTP/1.1: Header Field Definitions" href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1">et al</a>. But that's not what the article focuses on. Go read it. It describes use-cases for 
<a title="microformats" href="http://microformats.org/">microformats</a>.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>WWW Issuing 301s for www.cwru.edu</title
><link href="http://blog.case.edu/jeremy.smith/2006/08/05/www_redirects"
 /><id
>http://blog.case.edu/jeremy.smith/2006/08/05/www_redirects</id
><published
>2006-08-05T20:53:53Z</published
><updated
>2006-08-05T20:59:57Z</updated
><category term="HTTP" label="HTTP"
 /><category term="IT in Higher Ed" label="IT in Higher Ed"
 /><category term="case" label="case"
 /><category term="case western" label="case western"
 /><category term="case western reserve university" label="case western reserve university"
 /><category term="information architecture" label="information architecture"
 /><category term="it" label="it"
 /><category term="mainblog" label="mainblog"
 /><category term="web" label="web"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<p>I've long lamented the fact that 
<a href="http://www.case.edu">WWW</a> wasn't able to do 
<code>301</code> redirects for HTTP requests from 
<code>www.
<strong>cwru</strong>.edu/
<em>whatever</em></code> to 
<code>www.
<strong>case</strong>.edu/
<em>whatever</em></code>. 
<a title="Jeremy Smith's blog: What Do People Call " case="" western="" reserve="" href="http://blog.case.edu/jms18/2006/05/10/what_do_people_call_case_western_reserve_university">Quoting myself</a>:</p>
<blockquote>Heck, we're not even the first hit on a 
<a title="case - Google Search" href="http://www.google.com/search?q=case">search on "case"</a>. We are the #2 hit listed as "http://www.
<strong>cwru</strong>.edu" &#8592; oh the irony of running a web server on WWW that can't do simple 
<code>301</code>s.</blockquote>
<p>You may think that I am just being nit-picky because I have to be 
<a title="Jeremy Smith's blog: I Must Be the Most Demanding User in the World" href="http://blog.case.edu/jms18/2005/02/23/demanding_user">the most demanding user in the world</a>, but it's actually a pretty big deal. Search results and the ability to find information is a key ingredient of information architecture success.</p>
<p>Well, I have good news. I got an email last Friday from the Webmaster of WWW:</p>
<blockquote>
<p>Jeremy,</p>
<p>Just wanted to let you know that I put in a redirect on the Case webserver. Any requests for *.cwru.edu result in a 301 redirect to *.case.edu.</p>
</blockquote>
<p>
<strong>Woohoo!</strong> Our search results will finally gain some sanity. Below, I've taken screenshots exemplifying some of the stupidity of our current search results. Over the coming week, the search bots that index our site will take into account the 
<code>301</code>s, and a search over the 
<code>www.cwru.edu</code> domain will return the exact same hits as a search over the 
<code>www.case.edu</code> domain. In addition, the entire existence of a machine called 
<code>www.cwru.edu</code> will disappear and will never again appear as a result of a search.</p>
<div style="width: 575px; border: solid 1px white;">
<p style="width: 260px; float: right; border: solid 1px white;">
<a href="http://www.google.com/search?q=site%3Awww.case.edu+apply">Search for "apply" on www.case.edu</a>
<br />
<a href="http://blog.case.edu/jms18/2006/08/05/case%20search%20results%20for%20apply.png">
<img alt="case search results for apply.png" src="http://blog.case.edu/jms18/2006/08/05/case%20search%20results%20for%20apply-thumb.png" width="250" height="165" />
</a>
</p>
<p style="width: 260px; border: solid 1px white;">
<a href="http://www.google.com/search?q=site%3Awww.cwru.edu+apply">Search for "apply" on www.cwru.edu</a>
<br />
<a href="http://blog.case.edu/jms18/2006/08/05/cwru%20search%20results%20for%20apply.png">
<img alt="cwru search results for apply.png" src="http://blog.case.edu/jms18/2006/08/05/cwru%20search%20results%20for%20apply-thumb.png" width="250" height="165" />
</a>
</p>
</div>
<div style="width: 575px; border: solid 1px white;">
<p style="width: 260px; float: right; border: solid 1px white;">
<a href="http://www.google.com/search?q=site%3Awww.case.edu+email+settings">Search for "email settings" on www.case.edu</a>
<br />
<a href="http://blog.case.edu/jms18/2006/08/05/case%20search%20results%20for%20email%20settings.png">
<img alt="case search results for email settings.png" src="http://blog.case.edu/jms18/2006/08/05/case%20search%20results%20for%20email%20settings-thumb.png" width="250" height="165" />
</a>
</p>
<p style="width: 260px; border: solid 1px white;">
<a href="http://www.google.com/search?q=site%3Awww.cwru.edu+email+settings">Search for "email settings" on www.cwru.edu</a>
<br />
<a href="http://blog.case.edu/jms18/2006/08/05/cwru%20search%20results%20for%20email%20settings.png">
<img alt="cwru search results for email settings.png" src="http://blog.case.edu/jms18/2006/08/05/cwru%20search%20results%20for%20email%20settings-thumb.png" width="250" height="165" />
</a>
</p>
</div>
<div style="width: 575px; border: solid 1px white;">
<p style="width: 260px; float: right; border: solid 1px white;">
<a href="http://www.google.com/search?q=site%3Awww.case.edu+enrollment">Search for "enrollment" on www.case.edu</a>
<br />
<a href="http://blog.case.edu/jms18/2006/08/05/case%20search%20results%20for%20enrollment.png">
<img alt="case search results for enrollment.png" src="http://blog.case.edu/jms18/2006/08/05/case%20search%20results%20for%20enrollment-thumb.png" width="250" height="165" />
</a>
</p>
<p style="width: 260px; border: solid 1px white;">
<a href="http://www.google.com/search?q=site%3Awww.cwru.edu+enrollment">Search for "enrollment" on www.cwru.edu</a>
<br />
<a href="http://blog.case.edu/jms18/2006/08/05/cwru%20search%20results%20for%20enrollment.png">
<img alt="cwru search results for enrollment.png" src="http://blog.case.edu/jms18/2006/08/05/cwru%20search%20results%20for%20enrollment-thumb.png" width="250" height="165" />
</a>
</p>
</div>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>URIs Are Names</title
><link href="http://blog.case.edu/jeremy.smith/2006/08/03/uris_are_names"
 /><id
>http://blog.case.edu/jeremy.smith/2006/08/03/uris_are_names</id
><published
>2006-08-03T19:13:02Z</published
><updated
>2006-08-03T19:14:18Z</updated
><category term="HTTP" label="HTTP"
 /><category term="linkblog" label="linkblog"
 /><category term="rest" label="rest"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="Names and addresses" href="http://norman.walsh.name/2006/07/25/namesAndAddresses">URIs are names</a>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Web Oriented Services</title
><link href="http://blog.case.edu/jeremy.smith/2006/05/25/web_oriented_services"
 /><id
>http://blog.case.edu/jeremy.smith/2006/05/25/web_oriented_services</id
><published
>2006-05-25T17:03:41Z</published
><updated
>2006-05-25T17:03:24Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="linkblog" label="linkblog"
 /><category term="rest" label="rest"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="Does Java EE 5 getting REST mean WOA will break out? | Enterprise Web 2.0 | ZDNet.com" href="http://blogs.zdnet.com/Hinchcliffe/?p=43">REST puts the Web back into Web services by taking what's been so successful with the fundamental protocol of the Web, namely HTTP, and making it into a seemingly ideal Web services architecture.</a>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Lo-REST and Hi-REST</title
><link href="http://blog.case.edu/jeremy.smith/2006/03/19/rest"
 /><id
>http://blog.case.edu/jeremy.smith/2006/03/19/rest</id
><published
>2006-03-19T18:47:13Z</published
><updated
>2006-03-19T23:46:34Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="mainblog" label="mainblog"
 /><category term="rest" label="rest"
 /><category term="xml" label="xml"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>Via 
<a title="Dare Obasanjo aka Carnage4Life" href="http://www.25hoursaday.com/weblog">Dare Obasanjo's</a> post 
<a title="Dare Obasanjo aka Carnage4Life - ETech 2005 Trip Report: Building a New Web Service at Google" href="http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=83ec4876-7578-418c-8335-a3b0a147037b">ETech 2005 Trip Report: Building a New Web Service at Google</a>, this presentation 
<a title="Launching the Google AdWords API" href="http://buzz.blogger.com/media/minar-etech-2005.ppt">Launching the Google AdWords API</a>:
<dl>
<dt>Lo-REST (also called PoX/HTTP or "Plain old XML over HTTP")</dt>
<dd>the use of HTTP GET (or equiv) for information retrieval/query</dd>
<dt>Hi-REST</dt>
<dd>the use of HTTP PUT and DELETE (or equiv) for doing update.</dd>
</dl></div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>RPC Over HTTP is &lt;strong&gt;NOT&lt;/strong&gt; REST</title
><link href="http://blog.case.edu/jeremy.smith/2006/02/22/rpc_over_http_is_not_rest"
 /><id
>http://blog.case.edu/jeremy.smith/2006/02/22/rpc_over_http_is_not_rest</id
><published
>2006-02-22T21:11:31Z</published
><updated
>2006-02-22T21:13:48Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="linkblog" label="linkblog"
 /><category term="rest" label="rest"
 /><category term="web 2.0" label="web 2.0"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="30 Boxes API" href="http://30boxes.com/api/">30 Boxes API</a>
<blockquote>The 30 Boxes API supports the 
<a href="http://en.wikipedia.org/wiki/REST">REST format</a>.</blockquote>No, it doesn't. Piping function calls across over 
<code>HTTP GET</code>s is not REST. That's just a bastardized RPC scheme. 
<em>*Sigh*</em>... I guess the term "
<acronym title="REpresentational State Transfer">REST</acronym>" has officially become a buzzword. I guess everyone can begin using it interchangeably with 
<acronym title="Service Oriented Architecture">SOA</acronym> now. (See also 
<a title="GETSful | 2006-02-22 | BitWorking" href="http://bitworking.org/news/GETSful">GETSful</a>.)</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>A Note About Web Server Statistics</title
><link href="http://blog.case.edu/jeremy.smith/2005/10/12/a_note_about_web_server_statistics"
 /><id
>http://blog.case.edu/jeremy.smith/2005/10/12/a_note_about_web_server_statistics</id
><published
>2005-10-12T19:03:31Z</published
><updated
>2005-10-12T21:51:15Z</updated
><category term="Failures of Technology" label="Failures of Technology"
 /><category term="HTTP" label="HTTP"
 /><category term="mainblog" label="mainblog"
 /><category term="statistics" label="statistics"
 /><category term="syndicated feeds" label="syndicated feeds"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>Because I need to write this down. Web server stats are inaccurate and misleading. They do not tell you how many people view the content on your web site in a given month, in a given day, or in a given year. There are only two things web server stats are good for:
<ol>
<li>A number to show managers who tell you, "I need to see numbers to determine how synergized our forward-looking web costumer relations vision is!!!"</li>
<li>Determining server load.</li>
</ol>Many web savvy users use 
<a href="http://wiki.case.edu/news_aggregators">news aggregators</a>, like 
<a title="Bloglines" href="http://www.bloglines.com/">Bloglines</a>, to consume content. Using such software, the viewer never actually visits your site. The software does but not the reader of the content. In the case of 
<a title="Bloglines" href="http://www.bloglines.com/">Bloglines</a>, 9700 people might read your web site's content via the service; but it only appears in your web server stats once every couple of hours or so as it polls your 
<a href="http://wiki.case.edu/syndicated_feed">XML feed</a>. Additionally, your content may be duplicated in other places &#8212; 
<a title="Planet Case" href="http://planet.case.edu/">planet.case.edu</a>, as an example pertaining to the Case Blog system. So, according to 
<a title="Statistics for jms18.blog.case.edu (2005-10)" href="http://blog.case.edu/stats/jms18">my stats</a> for the 
<a title="Statistics for jms18.blog.case.edu (2005-09)" href="http://blog.case.edu/stats/awstats.pl?month=09&amp;year=2005&amp;output=main&amp;config=jms18.blog.case.edu&amp;framename=index">month of September</a>, I have had 2685 unique visitors. This doesn't include:
<ul>
<li>the 21 bloglines subscribers to my RSS 2.0 feed</li>
<li>the 7 bloglines subscribers to my Atom 0.3 feed</li>
<li>People who read my posts on Planet Case</li>
<li>the bloglines subscribers to Planet Case's XML feeds who read my posts there</li>
<li>the newsgator, netnewswire, rss2email, a 
<a title="Jeremy Smith's blog (syndicated by LiveJournal.com)" href="http://www.livejournal.com/users/jms18_case/">LiveJournal crossposting thingy I didn't even know about</a>, FeedOnFeeds, etc., etc., etc. bots that all poll my RSS or Atom feed and replicate the content elsewhere.</li>
<li>that same amount of different polling bots for the Planet Case feeds.</li>
<li>any other web sites that replicate my content</li>
<li>any other web sites that replicate the contents of Planet Case</li>
<li>Etc., etc. So on and so forth.</li>
</ul>Just had to get that out of my system. 
<strong>Update:</strong> And, 
<a title="CaseBlog:Info - CaseWiki" href="http://wiki.case.edu/CaseBlog:Info#Where_are_my_weblog_web_server_statistics">there</a> you have it. Statistics for group and organizational blogs. Hopefully I have not performed a detrimental service to the system for I agree with 
<a title="World according to Kieran, University of Warwick" href="http://blogs.warwick.ac.uk/kieranshaw/">Kieran</a> 
<a title="Jeremy Smith's blog: A Note About Web Server Statistics" href="http://blog.case.edu/jms18/2005/10/12/a_note_about_web_server_statistics#4533">below</a>.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Cross Server SSIs</title
><link href="http://blog.case.edu/jeremy.smith/2005/09/22/cross_server_ssis"
 /><id
>http://blog.case.edu/jeremy.smith/2005/09/22/cross_server_ssis</id
><published
>2005-09-22T17:23:23Z</published
><updated
>2005-09-22T17:28:28Z</updated
><category term="HTTP" label="HTTP"
 /><category term="mainblog" label="mainblog"
 /><category term="perl" label="perl"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<p>Here is my 
<a title="Grayden MacLennan's blog: Cross-Server Server Side Includes (SSI) Solved" href="http://blog.case.edu/gtm4/2005/09/22/crossserver_server_side_includes_ssi_solved">stab</a> at it, 
<a title="Grayden MacLennan's blog" href="http://blog.case.edu/gtm4/">Grayden</a>. I restricted proxying to an explicitly allowed set of hosts, made printing the resultant headers from the request optional, and enabled caching.</p>
<pre>
<code>#!/usr/bin/perl
use warnings;
use strict;
use CGI qw(:standard);
use LWP::UserAgent;
use URI;

###########################################################
## This work is licensed under the                       ##
## Creative Commons Attribution License.                 ##
## To view a copy of this license, visit                 ##
## http://creativecommons.org/licenses/by/2.0/           ##
## or send a letter to:                                  ##
##     Creative Commons                                  ##
##     559 Nathan Abbott Way                             ##
##     Stanford, California 94305, USA.                  ##
##                                                       ##
## Essentially this means you can do whatever            ##
## you want with the code as long as you credit          ##
## Grayden MacLennan (grayden.maclennan@case.edu)        ##
## as the original author.                               ##
##                                                       ##
## This document was last modified on September 21, 2005 ##
###########################################################


######
# httpgrabber.cgi
# by Grayden MacLennan
# grayden.maclennan@case.edu
#
# 2005-09-21
#
# This is a VERY simple program that grabs content from any
# http-accessible source and spits it out again.
#
# The original motivation behind this program was to allow
# me to do Server Side Includes (SSI) on one server while the
# included content sits on another erver.  Normally, SSI only
# works within a local file system, so this program in effect
# gives a LOCAL path to a REMOTE resource.
#
#
# --Example of usage--
#
#  What you'd do for a normal local file:
#
#    &lt;!--#include virtual="/somepath/includefile.inc" --&gt;
#
#  What you'd LOVE to do but can't:
#
#    &lt;!--#include virtual="http://remote.server.com/somepath/includefile.inc" --&gt;
#
#  What you do to get around the problem:
#
#    &lt;!--#include virtual="/cgi-bin/httpgrabber.cgi?url=http://remote.server.com/somepath/includefile.inc" --&gt;
#
#  To not print out the headers of the request
#
#    &lt;!--#include virtual="/cgi-bin/httpgrabber.cgi?url=http://remote.server.com/somepath/includefile.inc&amp;header=no" --&gt;
#
######

my @allowedHosts = qw(
                       blog.case.edu
                       www.case.edu
                     );

my $uri = URI-&gt;new(param("url"))-&gt;canonical 
    or die "URL parameter was not a well formed URL and could not be parsed";
my $ua = LWP::UserAgent-&gt;new;
my $host = $uri-&gt;host;
die $uri-&gt;host, " is not an allowed host to pull content from\n"
    unless grep /^$host$/, @allowedHosts;

my $mirrorFile = $uri-&gt;host .  join '.', $uri-&gt;path_segments, 'cache';
my $resp = $ua-&gt;mirror($uri, $mirrorFile);

die $resp-&gt;status_line if(!$resp-&gt;is_success &amp;&amp; $resp-&gt;code != 304);

my $printHeader = param("header");
print $resp-&gt;{_headers}-&gt;as_string unless($printHeader &amp;&amp; $printHeader eq "no");

{
    open CACHE, $mirrorFile or die "Could not open cache file because $!";
    undef $/;
    print &lt;CACHE&gt;;
    close CACHE;
}</code>
</pre>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Perl HTTP Load Balancing</title
><link href="http://blog.case.edu/jeremy.smith/2005/08/04/perl_http_load_balancing"
 /><id
>http://blog.case.edu/jeremy.smith/2005/08/04/perl_http_load_balancing</id
><published
>2005-08-05T04:34:57Z</published
><updated
>2005-08-10T22:46:44Z</updated
><category term="HTTP" label="HTTP"
 /><category term="linkblog" label="linkblog"
 /><category term="perl" label="perl"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="Perlbal" href="http://www.danga.com/perlbal/">Perlbal</a> &#8212; "a single-threaded event-based server supporting HTTP load balancing, web serving, and a mix of the two." It's what 
<a title="LiveJournal.com" href="http://www.livejournal.com/">LiveJournal</a> uses to balance its load.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Web Services Link Dump</title
><link href="http://blog.case.edu/jeremy.smith/2005/07/26/web_services_link_dump"
 /><id
>http://blog.case.edu/jeremy.smith/2005/07/26/web_services_link_dump</id
><published
>2005-07-26T16:03:03Z</published
><updated
>2005-07-26T16:04:31Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Programming" label="Programming"
 /><category term="Web Services" label="Web Services"
 /><category term="atom" label="atom"
 /><category term="mainblog" label="mainblog"
 /><category term="rest" label="rest"
 /><category term="syndicated feeds" label="syndicated feeds"
 /><category term="xml" label="xml"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<ul>
<li>
<a title="Sam Ruby" href="http://www.intertwingly.net/blog/">Sam Ruby</a> 
<a title="Sam Ruby: REST vs API" href="http://www.intertwingly.net/blog/2005/07/22/REST-vs-API">REST vs API</a>
<blockquote>
<p>At some point, you need to question the wisdom of having an API which abstracts away that which is important.</p>
</blockquote></li>
<li>
<a title="Integrate This" href="http://www.coactus.com/blog/">Mark Baker</a> 
<a title="Integrate This?Blog Archive ? Towards truly document oriented Web services" href="http://www.coactus.com/blog/2005/07/towards-truly-document-oriented-web-services/">Towards truly document oriented Web services</a>
<blockquote>
<p>Web services proponents [realized] that they needed to distance themselves from RPC and its well-deserved reputation as a poor large scale integration architectural style, due to the failure of systems such as 
<a href="http://www.corba.org/">CORBA</a>, 
<a href="http://en.wikipedia.org/wiki/DCOM">DCOM</a>, and 
<a href="http://java.sun.com/products/jdk/rmi/">RMI</a> to see any widespread use on the Internet. So, sometime in 2000/2001, collective wisdom in the space shifted towards a preference for "document oriented" services. Vendors quickly jumped on board with upgraded toolkits, and that was that; documents were the New Big Thing.</p>
<p>Unfortunately, the basic architectural assumptions underlying Web services at the time, didn&#226;&#8364;&#8482;t change nearly enough to distance Web services from the problems of RPC.</p>
</blockquote></li>
<li>
<a title="Bill de hOra" href="http://www.dehora.net/journal/">Bill de h&#195;&#8220;ra</a> 
<a title="Bill de hOra: Atoms in a small world" href="http://www.dehora.net/journal/2005/07/atoms_in_a_small_world.html">Atoms in a small world</a>
<blockquote>
<p>protocol driven extensions will tend to be mutually exclusive of each other and not an 
<a href="http://www.tbray.org/ongoing/When/200x/2004/04/01/WS-Mumble">interdependent monolith</a> as Web Services have turned out to be - that will make them easier to build and get deployed.</p>
</blockquote></li>
<li>
<a title="Understanding XML" href="http://www.understandingxml.com/">Kurt Cagle</a> 
<a title="Understanding XML: How RSS/Atom Is Replacing Web Services" href="http://www.understandingxml.com/archives/2005/07/how_rssatom_is.html">How RSS/Atom Is Replacing Web Services</a>
<blockquote>
<p>While I suspect that this commentary will be poo-pooed by web services vendors, the history of the web makes me suspect I'll be right in the end. RSS syndication has emerged in a largely ad-hoc fashion to fulfill a specific need - syndication - that seems to be an intrinsic characteristic and requirement of the Internet. Syndication in turn is simply a messaging protocol built around a subscription-oriented PUSH model. If you make the syndication format too complex for people to use (as I believe is the case with SOAP) then they will migrate to simpler formats as they become available. Because ATOM is blessed by both the IETF and the W3C and is seen as an open standard (whereas questions remain concerning the precise nature and implementation of SOAP) it will likely continue to gain the mindshare of developers and users alike.</p>
</blockquote></li>
</ul>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Atom Syndication Format</title
><link href="http://blog.case.edu/jeremy.smith/2005/07/15/atom_syndication_format"
 /><id
>http://blog.case.edu/jeremy.smith/2005/07/15/atom_syndication_format</id
><published
>2005-07-15T18:37:37Z</published
><updated
>2005-07-15T18:35:40Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Web Services" label="Web Services"
 /><category term="Weblog Tech" label="Weblog Tech"
 /><category term="atom" label="atom"
 /><category term="blog" label="blog"
 /><category term="linkblog" label="linkblog"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="The Atom Syndication Format draft-ietf-atompub-format-10" href="http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-10.txt">The Atom Syndication Format draft-ietf-atompub-format-10</a>
</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
></feed
>