Even working on a combined total of maybe 8 hours sleep for the past two nights (only about 3 hours the past night), day 3 definitely kept me awake.

It started off with a tutorial on Factor by Zed. I'd already been putting around a bit with it but the keyboard shortcuts he showed alone made it worth attending.

Next up was a very interesting keynote talk by Jon Udell. Jon spoke of the implications of the social web, where we are now, where we want to be later and a little on getting there. The example he gave that most stood out in my mind (that represented where we were) was of a widget he wrote for librarians so that people could easily check before buying a book if it was available at their local library. To use it, librarians would have to match up the ISBN code from the url of whatever software they used to keep track of their inventory in some pattern that would allow his program to check.

And librarians could do this. They would look at the long cryptic urls, spot out the key information, find the pattern and then, once one person did it, Jon's software worked for everyone that used the same program for inventory.

The problem came when some software just didn't play nice. For example, some required a post. While it's definitely possible to decrypt what's being sent through post (firebug will tell you for example), it's not something we can expect non-programmers to try and figure out.

So URLs matter. They convey information to the surfer about where they are and what they're accessing. Had the software been configured to work through URLs like http://www.library.com/books/[ISBN # here], it would have been extremely easy to parse.

So REST is part of the solution. Tim Bray agrees. REST stands for Representation State Transfer. If you've ever built a rails app you probably saw it in action. If more URLs were built to be representative of the data they convey, interaction between websites would be so much easier. Even my blog is guilty of not playing nice. Why is this url http://smokinn.tengun.net/wordpress/?p=234 ? That's terrible. Not only does p= say nothing, my blog is bound to the software used to run it! Even something like http://smokinn.tengun.net/blog/posts/2008-01-23/1/ would be better. The first blog post on the 23rd of january 2008. Or maybe something based off the title would be better, simpler to remember. Either way, URLs say something to the reader and ignoring them is a mistake.

Jon definitely convinced me of this and a web framework that I planned of reworking and hopefully releasing as open source soon might need some serious refactoring. I want it to play nicer with the URL. Right now navigation is based on the "action" and everything is passed through index.php. So you end up with a url like www.site.com/?action=something&other=something_else etc. We already use an xml file for breadcrumb navigation (to tell us that something is a child of home) so I could use that for REST architecture as well. I'm just not yet sure how I can make the server ignore all the forward slashes sometimes and not others. I'll look into that soon.

Where we want to be he illustrated through an old Apple video (commercial?) where the guy seamlessly did research by talking to his computer and issuing very vague commands (Show me that paper a few years back about rainforest waterfall. I found this paper by this guy, that paper by that guy, this paper by that guy. Summarize them. Overall they conclude this but this other guy contradicts them saying that. etc) and the computer can get the data he needs to do his work. Now it's possible to get the same data but only if you have a day to fish around looking for what you want. Even then you'll probably miss a bunch of stuff. While Google's motto of making the world's information accessible is a great one, we need to make it accessible to everyone, not just the people who understand how to use search engines efficiently.

So, in the end, Jon was one of the three speakers to have the most profound lasting effect on me once CUSEC was over. One of the others I'll be writing about tomorrow, the last keynote, Jeff Atwood.