Tag Archives: caching

Novo03

Christian Decker

4

OpenID Resources

I love OpenID, but it isn’t really trivial to understand how and why it works, but the Fred Stutzman at claimID have put together a huge list of resources about OpenID.
At ClaimID, we’re pretty enamored with OpenID. OpenID is going to make all of our lives easier, it makes our company more useful and valuable, and more and more smart companies are adopting the standard. That’s pretty exciting to us. I thought it might be useful to collect together some OpenID resources – so we can give our users a little roadmap to OpenID.

1 – What is OpenID?

  • OpenID website – Start here. This site has all the information you need on the distributed identity system that actually works.
  • OpenID Wikipedia entry – A very robust entry that covers a lot of the ongoing developments with OpenID. Do yourself a favor and just bookmark it now.
  • About OpenID – Brian Ellin’s bullet list description of OpenID with great links and Japanese translation.

2 – How does OpenID Work?

3 – OpenID Resource Sites

  • OpenIDenabled.com – This site, from the wonderful folks at JanRain, is host to tons of great information on OpenID. Documentation, protocol specs, how-to’s, FAQ’s – this site is extremely valuable.
  • IwantMyOpenID.com – The OpenID community marketing site and home to the OpenID 50,000 dollar bounty. Headed by Scott Kveton, this effort has had remarkable progress so far.
  • OpenID Mailing Lists - If you’re part of the OpenID community, you’re going to want to join this list. The latest list to be added is the necessary user-experience list.

4 – I want OpenID! Where can I get (and use) an OpenID?

  • ClaimID. Did you know that everyone who joins ClaimID gets an OpenID? Sure, you get all the other good stuff – caching, status monitoring, verification – but you also get an OpenID that you can use all over the net. We admit slight bias here.
  • All the other places. OpenID providers are springing up all over the net. The lists keep growing and growing! If you must use someone other than ClaimID for OpenID, we’re partial to JanRain’s MyOpenID.net, as this site is updated frequently and is very reliable.
  • Where can I use an OpenID? Sites include LiveJournal, Technorati, ClaimID, Wikitravel and Zooomr, with new ones being added frequently.

5 – I am advanced. I want some OpenID Software.

6 – OpenID Bloggers.


[via claimID Blog]
Did you like this? Share it:

Octo10

Christian Decker

0

Ajax and REST

As I wrote earlier I had the pleasure to read this very well written post over at IBM about why Ajax is a way to be RESTful. Bill Higgins starts by explaining what REST is and why it is important:
REST’s “client-stateless-server” constraint forbids session state on the server. Designing within this constraint promotes the system properties of visibility, reliability, and scalability. But immersive server-side Web applications wish to provide a great deal of personalization to a single user [...]
In short the REST-style allows us to keep simple resources that can be cached, and therefore take the load away from the server. Back in March I wrote a post explaining why Ajax is a better concept than traditional, session-driven, applications. It allows you to map a resource (the data that is needed by your application) to an URI, this allows you to keep those information-fragments well separated from the rest of the application, which will change its state during execution, while data probably wont. The “pure” data is separated from its representation and has become cacheable, and REST compatible, or as Bill explains it,

Going back to the Amazon.com example, imagine that you click a link to view information about a book on design patterns. In Amazon.com’s current application, the link click action sends a variety of information identifying the requested resource. It also sends various session-state artifacts that let the server create a new page that includes prior session state (such as recently viewed items), personalization information (such as “you purchased this book in 1999″), and the actual business resource itself. The application is very dynamic and highly personalized — but not cacheable and not natural scalable (though as Amazon demonstrates, these architectural problems can be overcome with millions of dollars of infrastructure engineering). Now consider this action in the (imaginary) Ajax version of the application. No processing needs to occur with regard to “recently viewed items.” This is simply information already present in the page that won’t go away when you click on a link. Two requests will likely be related to the design patterns book:

  • /Books/0201633612 (where 0201633612 is the design pattern book’s ISBN number)
  • /PurchaseHistory/0201633612/bhiggins@us.ibm.com

The first hypothetical request returns information about the book (author, title, descriptions, and so on); it contains no user-specific data. The absence of user-specific data means that as more users request the same resource, it is likely that they’ll retrieve cached versions of it from intermediate nodes on the Internet rather than from the originating server. This characteristic reduces server and overall network load. The second request, on the other hand, contains user-specific information (Bill Higgins’ purchase history for this book). Because this data includes personalized information, only a single user should ever successfully retrieve and cache the data from this URI. Although this personalized data doesn’t have the scalable characteristics of the nonpersonalized data, the important point is that this information is retrieved from a distinct URL and therefore has the positive characteristic that it doesn’t interfere with the caching of other application and data resources that are cacheable.

Personally I hope that this style of archieving things will be common practise in future. It makes things a lot easier, and solves many of the scalability problems we currently have :)

Technorati Tags: ,
Did you like this? Share it:

Julo02

Christian Decker

0

Cross-Domain limitation, a feature?

Many developers on the Web see the cross-domain limitation as a personal issue, they believe that it was just created to annoy them and force them to work arounds.

Besides being a security enhancement, the cross-domain limitation may also be seen as a feature, forcing the developer to implement some server side caching for the remote Service-provider, taking the load from it and securing that even if the remote service-provider has some downtime, some data will still be available.

Personally I think that we as developers have to protect the ones that provide us with data (XML-Feeds, JSON, …) and not bomb them with requests from our visitors until they can’t survive.


Technorati Tags: , , , ,
Did you like this? Share it:

  Recent Entries »