Has anyone tried using Amazon’s “RESTful” webservices? I’ve had many headaches using them. If I’m using PHP, I like to use nuSOAP to access SOAP services, because PHP’s facilities for XML (at least in version 4) are terrible. nuSOAP seems to have interop issues with some of Alexa’s/Amazon’s webservices, so that’s a pretty big turn off. The authentication requirements remain difficult/painful to implement, for some reason, even after doing it several times.

The focus on composability seems like a pretty nifty idea, however. S3 for storing things, and SQS for Queue services, EC2 is very cool for providing machines to run code on. The only problem is once you develop a client for one, you don’t have a working client for the others. They failed to provide a polymorphic interface to their services! On the web, this is really really bad form. In my short lived and naive experience, writing web services is primarily about two things:

1. exposing some logic controlling a persistence layer
2. organizing resources into logical units

These two activities become idioms, which become patterns. Open standards can save you a lot of work when it comes to interoperability issues, because they help define, or at least imply, how these patterns should be implemented. If amazon had used Atom Publishing Protocol, instead of the framework they are currently using, a single client implementation would be capable of consuming all their web services. What a mistake to not use it.

Furthermore, it’s a bit confusing as to why they labeled these services as RESTful to begin with, especially because they ignore the stateless requirements of GET, and put methods in the URIs. Any parser implementation intended as a component of a consuming application must learn how to individually parse each resource’s XML indepedently from the rest.

I’m not saying Atom Publishing Protocol is some magic silver bullet. I am suggesting that Atom Publishing Protocol helps you with one of the main tasks of developing web services: organizing and exposing resources.

Is anyone doing this? Yes. Google has added some extensions to Atom Publishing Protocol, and has called it GData. If amazon wants to compete with google in terms of being a platform, it’ll need to simplify the ways consumers get access to resources while increasing the surface area of exposure. One way to do that is to make sure that the burden for developers is very low, such as providing a single consistent interface (which HTTP already provides, and web architecture strongly implies) capable of consuming all your resources.

Common’ Amazon! Fight NIH! Don’t re-invent: re-use the known good patterns and idioms for publishing on the web. Atom publishing protocol is one possible codification of those common idioms and patterns, and it’s an open standard. It might not work out, but it’s certaintly seen a lot more peer review than your unRESTful web services model.

The W3C has restructured some working groups in the Interaction Domain. The new HTML working group is co-chaired by Dan Connolly of W3/MIT and Chris Wilson from Microsoft.

Both WHATWG and W3C are pursuing an improvement in HTML while simultaneously adding new features. My reading of charts seems to indicate the following:

• WHATWG is focusing primarily on disambiguation of the HTML spec to trigger developer adoption, with new features as a secondary goal.
• W3C is focusing primarily on new features to trigger market adoption with disambiguation/improvment as a secondary goal

Over the last few years, as my interest in usability has grown, I have also become curious about the issues surrounding how technology becomes adopted by society. Contrary to intuition, when a new technology becomes available, society at large takes a long time to adopt it. When zippers became available, it took 100 years before they became popular in clothing. Zippers offered a new and clearly superior technique for fastening over buttons, however, despite garment fastening consistently being one of the primary use cases for zippers, it took a long time before society actually started using zippers. (I recommend Evolution of Useful Things.)

While I’m glad for the effort of the W3C and WHATWG, and even look forward to participating in some of that work, I’m a bit cautious regarding their expected outcomes. What is the plan for pursuing adoption? I’m not convinced that adding new features is enough of an incentive to trigger market adoption because that model doesn’t fit the historical record very well. If there’s anything I’m learning, it’s that constant iterative improvement that is responsive to previous failure is the single most important process to improve technology with regard to market and societal adoption. Seeing the future is harder than seeing the past.

The WHATWG has a huge jumpstart over the W3C on discovering what the problems with the original HTML were. I sort of think they would be better off in a Firefox kind of methodology: spend defined periods of time alternating between fixing past faults and adding new features. Shorten the feedback loop to discourage hegemonious implementations from running the market.

The WHATWG has active involvement from browser vendors, and many content producers and developers. W3C HTML WG has just started, and probably has the most inclusive participant policy to date. Anyone can become an “invited expert” by successfully filling out a few forms. I’m currently in the middle of this process. The group’s co-chair is from Microsoft, but I believe Microsoft’s presence is completely absent in the WHATWG processes. While IE7 and the team that worked on it has focused on improving IE to become more conformant to interoperable standards, the legacy of IE6 and Microsoft’s historical commitment to open standards weigh heavily in my mind. What dynamics will determine how these groups work together?

I suppose we’ll see what happens in the months and years to follow.

I’ve been looking into distutils stuff lately. It seems like really nice stuff… it’s capable of all sorts of nice things. One of the things I’d like to do is add some commands for creating releases, which involves automatically creating a release branch in perforce. I was having a lot of trouble getting enough information to do this, so here it goes. I also found a very informative skeleton on lesscode.

class HelloWorld(Command):
  """This is a simple hello world command addition."""
  # user options is a list of tuples. each tuple conforms to:
  # ('long-arg-name=', 'a', "Description of option.")
  user_options = []
  command_name = "helloworld"
  def initialize_options(self):
    pass

  def finalize_options(self):
    pass

  def run(self):
    print "hello world."

You’ll also need to add setup(cmdclass={'build_py': build_py}, ...) to setup.py, as explained in the python docs.

&emailre=bewest@gmail.com&ticketkeyre=d7f62b8b&_i=BAU-34900

I hope they eventually realize their ticket system isn’t secure, and that putting credit card numbers in tickets is a very bad idea.

UPDATE: I started hunting around for more information about this company. Evidently the Better Business Bureau can’t even figure out basic information about SeverPronto / InfoLink. The “address” they publish is simply a drop box, not a physical location. Buyer beware!

Finally got mercurial to get served to the web using fastcgi under lighttpd. It took me about a full day to get it working, so I’d like to explain what I did so that someone else doesn’t struggle as long as I did.

This is just a really brief note: you should already be familiar with lighttpd configurations, as well as mercurial configuration.

I was interested in getting push/pull to work over http, so I grabbed version 0.9.3 of mecurial. Next, I set up the directory structure I wanted. In the place where I want the fastcgi script to run, I used a very simple script:

from mercurial.hgweb import hgwebdir_mod
from flup.server.fcgi import WSGIServer

from mercurial.hgweb.hgwebdir_mod import hgwebdir
from mercurial.hgweb.request import wsgiapplication

configFile = '/opt/www/fastcgi/changes/hgweb.conf'

def make_web_app():
    return hgwebdir(configFile)
# evidently wsgiapplication expects a callable, not an object.
app = wsgiapplication(make_web_app)

WSGIServer(app).run()

I was able to get the page to render using a typical fastcgi setup in lighttpd, however with every request, I was seeing this exception in the error log. Some debugging in IRC was fruitful, once I was able to ask the right questions. I was shown a fix to the headers values must be str error, and so I manually edited it myself. I’m sure I’ll be kicking myself eventually when this comes back to bite me later. For, now I’m happy that the basic configuration seems to be running and working.

I was also just shown a script to run hgwebdir over fastcgi. Too late for that to help me now, but maybe it’ll help someone else.

Technorati Profile

All it takes is a little link and technorati knows more about you and your blog.

What is OpenId?

OpenId is a way to provide identity over the web. A URI that represents your credentials is requested by services you access that require you to identify yourself. Since this requirement is very common, monotony and affordance provided by the service of your choosing makes it no more difficult than ordinary browsing to access private and secure resources.

The Story So Far

As the web gained prominence in everyday culture, people started to more fully appreciate the difference between GET and POST HTTP verbs and “friendly” urls. Today, many business owners recognize the value in SEO and have a basic understanding of how their website’s URIs fit into the picture.

To protect users’ resources, many web developers also started including authentication components into many systems. The proliferation of useful web applications and services is creating a tremendous burden on the public to remember many instances of usernames and passwords. The burden is so great, and the rules for credential validity so varied, that many people, including myself, often resort to using (or attempting to use) the same username and password. In addition, in extreme cases, users resort to writing down the most sensitive credentials, because the rules for sensitive credentials tend to be incompatible with the user’s habitually prefered credentials.

An Excellent Tool

By using OpenId, you save yourself from having to write lots of painful code to deal with logging in and SQL plumbing. You also make your services much easier to use. By participating in a system whose value behaves according to network affect, your service also becomes more valuable. See the Wikipedia OpenId page for more details.

Wikipedia has a regular document structure. In fact, one of the benefits of wikis is that it allows users to focus more and content, and less on style. Therefore many wikis have a regular emergent document structure that can be more or less predictably parsed… anyone up for an expert interface to wikipedia???

Linked Data

Every piece of data has a URI. The way you access an object is by dereferencing it’s URI. The result is a kind of ORM over the web. I don’t really like that phrase, “ORM over the web”, so if you have a better suggestion, please tell me.

ElementTree and Python

I’ve been wondering about how to instantiate objects over the web. SOAP is ok, but I think this idea of using HTTP and URI’s is better. I indicated in an earlier post I was leaning towards using element tree because it allows you to turn an XML document into a more native, pythonic object. I guess I wasn’t alone. This class shows how to do it over http. Although, they go another direction with POX and xml-rpc.

No muss, no fuss.