If you use sessions to track logins the session key acts as a password equivalent while the session is active. So if anyone can intercept that session key they can masquerade as the logged in user without knowing their actual password. Hence, sessions time out to improve security by giving only a small window that the session key can be used in.  This of course drives users crazy because they have to login again and again.

Flow|State has an excellent semi-rant about how poor the user experience is when using OpenID – both signing up and logging in. In particularly the question of what happens to all your accounts when your OpenID provider disappears is a particularly good one.

It so happens that I was looking into this just today since I needed a user friendly but secure authentication mechanism. OpenID seemed like a natural choice since I was effectively starting from scratch anyway, why not use a standard? The main problem I had with OpenID didn’t really come through clearly in the Flow|State article though – OpenID requires users to log in twice. The first log in requires them to enter a URI, the second log in requires them to enter their password (or in some cases a username and a password). It’s bad enough that most URIs are much longer than most usernames or even email addresses, but there’s actually a page reload between the URi and the password. When was the last time you saw a webapp display the username and passwords fields on separate pages?

I have to agree with “Jon”, Gruber (John with a h) does have a habit of linking to sites that link to him regardless of how good they are. For instance, this link list entry was a complete waste of time…

I wonder if there’s any limit to it?

I’ve struggled with Lucene before and failed to configure it properly resulting in absolutely horrendous search results so a recent need to implement search functionality wasn’t something I particularly wanted to take on. In fact, I was prepared to do almost anything to avoid delving back into Lucene filters and parsers and tokenizers and “stuff”. This tends to be problematic given that Lucene is the dominate search library – so popular in fact that it’s been ported to other languages.

Alex Iskold has an interesting article “Rethinking ‘Crossing The Casm’” which asks how to maintain the interest of early adopters in the face of such an overwhelming number of new products:

According to Wikipedia in 2006, Tom Byers, Faculty Director of Stanford Technology Ventures Program, described “Crossing the Chasm” as “still the bible for entrepreneurial marketing 15 years later.” It is certainly a powerful and proven theory, but it does need to be adjusted. The fact that so many things are thrown into the market changes things. Early adopters are enticed by new things much more often today than 15 years ago. Expanding on how to retain the early adopters would be good thing to do in the next edition.

There’s this myth that’s existed ever since the beginning of OS X – that Cocoa apps are automatically better than any other type of application. They use less RAM, run faster and are just all round better – you can’t dispute it. If you take a lousy carbon app and rewrite it in Cocoa it will become amazing and all it’s problems will be solved.

This is of course, complete and utter bull.

I’ve been setting up a site for my wife and I to help us keep in touch when we move over to the UK next year and to let us share photos with friends and family etc. Of course this leads to the fun of picking a domain name that makes sense for us and is easy to remember. Going through the list of names we thought up, “thesuttons” was the only one that we liked and was available – but only in a few TLDs.

Just as I’m catching up on Amazon’s web services, they introduce another one – this time aimed at payment processing. My first impression though is pretty underwhelming. The one thing that FPS seems to have going for it is that it is extremely flexible. Most processing systems focus on moving a specific amount of money from a credit card to the sellers account. FPS provides options for combining micro-payments, direct debit (and proprietary Amazon funds) as well as recurring payments etc. In other words, FPS provides a ready made billing department rather than just an order processing system.

I’ve done a fair bit more investigation into using EC2 for web hosting and it seems to be something that people do with a fair bit of success. In addition to Geert who commented on my last post and who’s site rifers.org is hosted directly on EC2, there’s also hanzoweb.com and www.gumiyo.com all of which just have their DNS pointing at an EC2 instance.

I still wish Amazon had a preconfigured solution that acted as the web front end and load balancer with a static IP, but it appears that it’s quite feasible to just point your DNS at EC2 and your server seems to stay put.

The Ephox Weblog pointed me to James Robertson’s comments on Seth Gottlieb’s article, “Homebrew CMS” all of which is good reading. The key part for me is:

Editing environment. If the authors can’t easily and efficiently get their words onto the site, you’re toast. There’s a huge amount that goes into a good editing tool, including table support, CSS, images, spell checking, and clean cut-and-pasting from Word. Even if you chose to use one of the commercial editing tools (a good idea!), it still needs to be tightly integrated into the CMS.

One of the common first steps for scaling up an application is to move the database off to a dedicated server – often followed by having multiple application server instances to handle requests. With a standard SQL database that’s pretty straight forward, with data stored in Amazon S3 that’s not always as simple.

S3 obviously provides a network API, but it doesn’t necessarily provide all the functionality you need from your data layer. For instance if you need to update search indexes you need a central server to track the changes and update the indexes. You may also need synchronization above what S3 provides etc. Whatever the reason, you need to provide a server to handle those data layer tasks and then pass the storage off to S3.

I like the idea of resources being addressable by a simple URL, but I’m having some difficulty reconciling that with resources that are versioned. Getting at and working with the latest version of a document with REST APIs is all pretty straight forward, but how do you retrieve the document history or a specific version of the document? I’m sure this is something that people have already worked out, but all my searching for discussions of it leads to people talking about versioning the API so that things don’t break when you change what operations are available or the data format returned, rather than versioning the resources themselves.