(Or, Yes! Your Crappy Hosting Service and Silly Language Should Work)
Innovation on the web comes from many different directions, and a surprising amount from people with very limited resources. The falling costs of hosted environments and the availability of cloud services like Amazon’s EC2 and S3, are bringing a whole new dimension to what a web application is, and the profile of the people who build them.
If you go back and read my first few posts to the OAuth mailing list, you will see how my initial attitude was to treat everything as a C++ developer. What am I talking about? The attitude that developers always have full access to every feature of the hardware, operating system, and network, and should take full advantage of it. The attitude that treats everything as if it was as easily accessible as making an HTTP GET request. While this is almost always true in C++, it is far from true in many other languages.
I am getting a lot of this attitude now from folks at the W3C and IETF when talking about new specifications. It usually comes up when talking about HTTP methods such as OPTIONS or using DNS for discovery. One of the key requirements in my Discovery and HTTP analysis is Scale Agnostic:
I call this the Equal Access Principle . The principal, simply put, asks protocol designers not to be snobs. It states that protocols should be able to operate not only on the most powerful frameworks, but within the constraints of the limited frameworks which are part of the web reality. It is a sort of socialism for protocol architecture. We take away some power from the top to make sure those closer to the bottom can also play along.
On the other hand, while designing host-meta, we decided to limit the protocol to those with access to the HTTP server root. It made sense for host-meta because the cost of buying a custom domain and hosting HTTP resources is so low, it is practical for anyone to implement.
One of the first successful specifications to promote the Equal Access Principle is OpenID. While other protocols take into account such limitations (JSON is one example), the authors of the first OpenID specification (and later the authors of the Yadis protocol) made it their top priority. If you study the protocol, the Equal Access Principle marks are all over the place.
The irony with OpenID, is that it takes such extreme measures attending to the weak, it significantly disadvantages the strong. The requirement to add headers or elements to every OpenID-capable URI, or risk problems with caches using content negotiation has led many of the large providers to invent hacks to make OpenID work.
The Equal Access Principle dictates equality. It doesn’t matter how big or small you are, the protocol should find ways to work well for both.
Liked this post? Follow this blog to get more.