Superscalar Task Management: A Different Approach to User Routing

Users and programmers don’t think in terms of means; they think in terms of goals. No one cares that they have to open Thunderbird, click Address Book, and then search to find a phone number. They just want to find a phone number. So, why are we programming and using web sites any other way? Right now, as programmers, we have to manually route users around a site. On the OpenID server I’m currently programming for Four Kitchens, routing a user through the authentication process is tedious. When a user first arrives to authenticate, he or she has one goal, authentication to the “OpenID Consumer” site. This goal has two dependencies, authentication with the OpenID Server and authorization of the OpenID Consumer site through the user’s trust roots. A user can have any combination satisfied. That means I have to consider four different routes (2^2):

• State: User is authorized with OpenID Server
  State: OpenID Consumer is under the user’s trust roots
  Action: Pass-through
• State: User is authorized with OpenID Server
  State: OpenID Consumer is not under the user’s trust roots
  Action: Authorize trust root
• State: User is not authorized with OpenID Server
  State: OpenID Consumer is under the user’s trust roots
  Action: Authenticate
• State: User is not authorized with OpenID Server
  State: OpenID Consumer is not under the user’s trust roots
  Action: Authenticate
  Action: Then, authorize trust root (must be in this order)

If we had a superscalar-style task management system, we would have a set of tasks with dependencies. The system would be responsible for scheduling the dependencies to satisfy them. We can break authentication to an OpenID Consumer into three tasks (in no particular order):

• Task: Authenticate the user to the OpenID Consumer site
  Dependency: Authentication to the OpenID Server
  Dependency: Authorization of the OpenID Consumer under the user’s trust root
• Task: Authenticate the user to the OpenID Server
  Dependencies: None
• Task: Authorize the OpenID Consumer under the user’s trust root
  Dependency: Authentication to the OpenID Server

But, unlike a regular superscalar architecture, the programmer would (as directly above) establish tasks, dependencies, and means of accomplishing tasks beforehand. The running system would only need to set goals. The system would even determine a viable, short task path to accomplish the goal. With such a system, authenticating a user to an OpenID Consumer would be simple. The programmer would establish the controllers (as in MVC) that accomplish the tasks. When a user needs to authenticate, the running system would merely add a goal (authenticate to a given OpenID Consumer) and tell the system, “Go.” No more complex routing logic in every controller.

Commenting on this Blog post is closed.