diego's weblog: March 2005 Archives
It begins: "this would be interesting to blog about." Some notes are made. Thoughts organized. In-brain sessions held, middle of the night, smoke-filled-backroom-atmospheric-like. Then nothing happens: you're too busy. Busy, busy, busy, busy. "Tomorrow," tou think. Tomorrow turns into Tomorrow again. Ideas accumulate. Things you wanted to comment on further start to become stale. Events pass you by. There's another earthquake! Grokster v. MGM is in play, and everyone talks about it, even if a decision is not expected until June or thereabouts. Services launch. Get invited to some of them, use them. Even more things to talk about. Even less time.
Comments are posted, page rebuilds, and MovableType's all-seeing all-knowing configuration with its "show posts for last seven days" (which you keep forgetting to find some way around) suddenly yields an empty page. Blank.
But a blank page is full of possibility too. Like a desert.
And hey, Spring is here!
Sort of. :)
the problem with scoble's linkblog
While I enjoy perusing Scoble's linkblog when I have time (there's pointers to a ton of interesting stuff in there) I have not been so thrilled about his full-republishing technique. In my opinion, the question who exactly created the content is going to be slightly confusing for someone arriving there from a search engine (this in particular for people that don't yet know what blogs are, much less linkblogs).
Even if it was obvious though, the fact that he is republishing articles/posts wholesale without explicit permission means that a reader that would otherwise end up in my blog suddenly has no reason to do so. I have avoided commenting publicly on this, waiting to see if it changed, but it hasn't.
For example, check out his reposting of my take on AJAX. It's a long post (something relatively common for me) and by the time you scroll down to the second paragraph, you have forgotten that URL at the top. Many people will just get to the end, and move on to the next linkblog post.
Republishing content wholesale without permission is a bad idea. And a linkblog is supposed to be made of links, not full posts.
Robert, I suggest you simply post links and titles, rather than full posts---at most, a 50-word snippet or comment would do (similar to what Kottke does for his linkblog posts). If you think that's unreasonable, I'd ask you to remove any posts of mine that you may have republished over there and to avoid republishing other posts in the future. Thanks. :)
"forget oil" revisited
Almost a year ago I posted a short entry titled forget oil. Aside from the facts that bottled water costs more than gas at the pump in every country I can think of, and that more than one sixth of the world's population still has no running water, this New York Times article on China's river-management policy caught my attention. "Something to keep in mind" indeed.
more on ajax
But assumming that AJAX apps prosper, I think that we'll just circle back, realize that we're facing the same problems, and then find solutions based on our previous turn on this particular loop. Maybe this will another step towards what Marc Andreessen hoped (almost ten years ago, and I still remembering reading that article!): "A secure, truly mobile agent language -- way beyond Java -- will eliminate the Tower of Babel that prevents us from harvesting more of the benefits of computing and communications today."
quote of the day
If you can't stand the heat, get out of the kitchen.
Harry S. Truman
Why do I say that AJAX is an old idea reborn in a different form? To answer that, allow me to take a little detour.
How web apps (used to) keep state, or the thin client way
Originally, a browser+HTTP+server combo was a stateless content-retrieval system. As more complex logic was added, browsers remained "thin" in that held very little state information. Cookies (on the client side) and Sessions (on the server side) were created to address that as more complex applications were brought online. But the limitations of cookies for data storage mean that they are used primarily for two things: initialization information (e.g., automatic login to websites) and historical or subscription data (although even in this case cookies are largely used as browser-held keys that point to more complete server-side DB records). Sessions, therefore, have remained the primary method to maintain state through the lifecycle of a web application (Some data can be held in the web pages themselves, e.g., hidden form fields, but that data has to be passed back to the server on each request). The problem with keeping sessions in the server is that, for nearly all significant operations, the client has to go back to the server to present a result, and it has to do it through the core UI thread, leading to a diminished user experience.
The problem this creates is that as long as we're not all accessing the Internet over low-latency T3 lines, and as long as servers experience load spikes, unexpected loads, etc., the user experience of web applications (via thin clients) differs significantly from that of client-side applications (fat clients). AJAX bridges this gap by creating what amounts to (cue reference to Douglas Coupland's Microserfs) a "thin-fat client."
AJAX: web client/server, or the rise of the "thin-fat client"
In the early 90's, the buzzwords du jour were "client/server systems". These were systems where PCs actually performed a certain amount of processing on data obtained and passed back through tightly coupled connections (typically TCP). As important as servers were in that scheme, one of the keys of client/server computing was that the client maintained most of its state. True, the server did maintain a certain amount of state and logic (just keeping state on a TCP connection would count, for instance), but it was the client that drove the interaction, that kept information on a user's location in the dataflow, etc. The web, however, changed all that.
If the web thin client model decoupled UI from processing (at least relative to client/server), AJAX allows for a flexible "free form coupling" when necessary. By pulling more data-management logic back into the client, AJAX goes back to a more traditional client-server model. True, the server could maintain state if necessary, and undoubtedly some AJAX-powered applications, such as Gmail, do so to some extent. But consider the difference between Google maps and, say, Mapquest. Mapquest stores the current view's data in hidden fields in the page, which have to be sent back to the server on each request. While this is, speaking strictly, stateless operation, the server has to re-create the state of the client for every request, modify it as necessary, and then send it back. Google maps, on the other hand, can keep the state on the client, requesting new data from the server as the user moves around the map, zooms, etc. The result? The server is freed from creating/keeping/updating state and goes back to doing what it does really well, which is serve data.
So does this mean that we're going back to client/server? Doubtful. There is no silver bullet. As cool as AJAX apps (like Google Suggest, Google maps, or A9) are, I suspect that AJAX's greater value will be to add another tool to the toolset, allowing for hybrid thin client/fat client applications that improve web UI interactions and bring us to the next level of distributed applications.
opml, icons, and the nooked rss directory
The question was: if the white-on-orange XML icon is a common way to identify RSS feeds, what's the equivalent for OPML?
One answer was to use the same icon, which is in fact generic, to represent OPML as well. This solution, however, can be used when you have either one type of output or the other, but not both at the same time. Another possibility was to use one of the many different icons that turn up in a Google Image search for opml. Another option was of course to create an entirely new icon. The problem was to come up with something that a) wouldn't be unfamiliar to users, b) would be unobtrusive and c) would maintain the value of the XML icon for the RSS feed.
On one hand, the line was crossed long ago when different applications overloaded the XML icon, and even its Look and Feel, while changing its contents (Yahoo! for example has modified the original icon here and they also have a similar-looking icon with "RSS" instead of "XML" to subscribe to Yahoo! Groups, example -- there are many others, I'm not singling out Yahoo! in particular). On the other hand, there's no need to create even more confusion. Dave has advocated the use of the XML icon for the appropriate XML output for a page (be that RSS, OPML, etc), and, maintaining the value of the icon by avoiding changing its contents while keeping the look and feel intact. After some thought, I concluded that in this case the second approach made more sense: barring a particular design or business need (for which there are many good examples, but that weren't a factor in this case) simplicity was the best option. Additionally, avoiding possible user confusion that would result from a non-standard icon is definitely a good thing.
So what I ended up doing was to maintain the common XML icon to point to an RSS feed (the most accepted use of it by far) and to link to the OPML using a simple text link, enough to be unobtrusive while remaining usable for those that know what they're looking for (after all, not everyone knows what "OPML" is). As it turned out this was a fourth option: have no icon at all.
For example, check out the directory's Arts & Humanities page. The same page can be viewed as OPML and as RSS. (The link to the OPML view is still there, to the right --- Nooked replaced the link that directs to the RSS view with a small ad after I delivered the app, so essentially imagine that the white-on-orange XML icon is where the Nooked ad is).
Interestingly, this solution was also pretty good in terms of matching the functionality needs that we had (unobtrusive and at the same time easy to identify for experienced users).
Related: there's some cool stuff that can be done by using the OPML output as a start, for example, reading the OPML of feeds listed in a category and presenting a full RSS data view of them (different from showing the entries of the directory in RSS, which the directory does) with little coding. Then the loop could go on by creating OPML views of the category feeds, and so on... interesting possibilities for meta-aggregation and possibly other kinds of data processing/analysis.
a st. patrick's day story
Happy St. Patrick's Day everyone!
Since this is the first time in three years that I'm not in Ireland for St. Patrick's, I thought I'd do a little blog-remembrance while having a Guinness.
While in Dublin it is common to come across groups of drunk people late at night in the weekends (and sometimes during the day!) it becomes even more common during this holiday. Many of those are not necessarily Irish, mind you, since there's a huge influx of tourists during this week every year (between half a million and one million if I remember correctly).
Now, in St. Patrick's day, 2003, I was heads-down working on what would shortly become clevercactus pro. It was a night of deep fog, and I was working quite late (as usual). Around 3 am, I hear sounds coming from the door. Sounds that indicated that someone was trying to open the lock. Coming out of flow state, slightly confused, I walk to the door and look through the peephole. A man is standing there, looking with confusion at a set of keys in his hand, with which he had evidently tried to open my door.
"Hello?" I venture, non-committal.
Now, all the doors in the complex look alike, so I understand some level of confusion. But you really have to be wasted to not remember what apartment number you live in.
I assume he eventually went through all the apartments and found his, after all, there was only one more floor to go.
Unless he was in the wrong building of course. :)
I have absolutely no idea what I'd do with a bunch of Gumstix Waysmall systems, but, like Cringely, I keep thinking that there's something cool that one should be able to get them to do. A mini-cluster, connected via bluetooth! Right, but for what exactly? Anyway. Certainly something to keep in mind for when I need a swarm of tiny computers to do something. :)
OpenSearch is a collection of technologies, all built on top of popular open standards, to allow content providers to publish their search results in a format suitable for syndication. [...]Cool!
First Yahoo and now A9 are now pushing the boundaries of Search APIs. Google's API, sadly, remains in its usual we-don't-seem-to-know-what-to-do-with-this-or-want-to-support-it state. Maybe all of these announcements will spur Google to crank it up.
there and back again
The objectives of [this software] are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently.Hm. Where did I get that from? Gnutella? Freenet? Some other fancier P2P app?
Nope. It's from RFC 959, circa 1985, which defines the FTP protocol (RFC 765, which it obsoletes, dates from 1980). "To promote sharing of files (computer programs and/or data)". Ain't that a riot?
One of the points I made in my thesis was that initially the Internet was truly a P2P system, and only later it moved into the client/server direction, only to slowly creep back into decentralized mode. FTP, which we hardly think about anymore, was a great example of this that I didn't use.
Consider that the original mode in which FTP worked was one where the client was actually a server as well. How so? Well, these days most FTP connections are "passive mode" connections. The "passive" there is talking about the ftp client. Normally, an FTP server accepts connections along with a port specification on the client. The server then opens connections to the client, which must have its own server for that. Passive mode enabled clients to open all connections themselves, a clear necessity as systems started to find themselves behind firewalls, NATs, and such.
The point is that even FTP, which we tend to think of as one of the prototypical client/server applications, was actually one of the prototypical peer-to-peer applications. The client and server divided the load, clients being responsible for serving transfer connections, and servers for the serving control channel connections.
There are many "loops" of this sort, sometimes repeated decade from decade. A lot of computing has been about making the same things easier, faster, or more scalable. And what's important about this is that, hard as it might be, it's always useful to know what happened before, from the 60s onward. Revisiting ideas is fun, as long as we avoid revisiting the mistakes: we should be trying to make new mistakes, not repeat the ones from the past. :)
PS: let's see how long it takes someone to note the title of the book from which the title of this entry was, er, "downloaded". :)
**The white light fades, revealing GandalfTo which one can only say: LOL!
Then we've got Andrew Sullivan who thinks that society is dead. Why? Because people in Manhattan listen to music on iPods rather than to the noise of traffic and such. Right. Lighten up, dude. Music players have sold, since inception, maybe, what, 100, 200 million units? There are about 6.3 billion people in the world without music players. Maybe society isn't dead quite yet? More than a billion of them don't even have running water, but they haven't "fallen under the spell of iPods" either. So it ain't all bad...
iPods and blogs. Now, that is something that should keep you up at night.
Woody Allen comes to mind: "What if everything is an illusion and nothing exists? In that case, I definitely overpaid for my carpet."
Also, Adam Curry: "Veni, Vidi, Velcro."
While working, I've spent half a day listening to U2, the other half to Sinatra. Both rock, even though Sinatra didn't. Language is funny that way. If I was really feeling recursive, I'd say funny, not ha-ha funny (like this Bono vs. Carly post is), which in itself is funny, but not...
Well, what do you know, I guess I am feeling recursive.
The technique works by "exploiting small, microscopic deviations in device hardware: clock skews." In practice, Kohno's paper says, his techniques "exploit the fact that most modern TCP stacks implement the TCP timestamps option from RFC 1323 whereby, for performance purposes, each party in a TCP flow includes information about its perception of time in each outgoing packet. A fingerprinter can use the information contained within the TCP headers to estimate a device's clock skew and thereby fingerprint a physical device."Wow.
listen. think. act.
And get started by watching Bono's speech to this year's TED conference. The whole address is about 30 minutes. Highly recommended.
back into the flow
I've been really busy the last few days, and blogging has suffered. Oh well. I expect this will continue to happen for the foreseeable future. :)
I am really enjoying the weather here. Truly fantastic. One thing I miss, though, is Webvan, which was really great. I have to try out Safeway and see how it goes--otherwise shopping is kind of a pain since I don't have a car yet. But, you know, biking back and forth to the office actually makes up for it. Particularly in this weather.
Did I mention I'm enjoying the weather? :)
new mobibot, new GoogleME
Erik has released a new version of GoogleME and a new version of mobibot. Very cool. I still don't have a local phone, but once I do I'll actually be able to use the local features of GoogleME (which weren't very useful in Ireland :)). Also, mobibot is now uploading directly to del.icio.us, which is a great example of the use of the delicious API. I still have to make some time to play with that myself!
yahoo! wakes up
I keep saying that Yahoo! doesn't get enough credit for the stuff they do (probably because they have so many services and systems that it's difficult to see a "simple narrative"). Maybe this will start to change things.
the nooked rss directory
The directory is an interesting app: basically a resource of corporate RSS feeds (including Podcasts). Data is still being added, so there are some categories that don't yet contain many entries. One of the points of this particular app is that there is "editorial control" (similar to the Yahoo! directory) and so a level of relevance should me maintained throughout the entries.
While the nature of blogs (and the web itself) makes centralization difficult to maintain, directories are of course useful resources, and in this case, for many people that are only now approaching RSS from a corporate communications point of view, the directory would be a useful resource to get started and find information on the companies or products that they are interested in, and they could submit their own feeds.
It took a bit longer that originally planned, but it's great to finally see it deployed. The OPML view of the listings has some interesting consequences--but that's for later! :)
Copyright © Diego Doval 2002-2011.