So the calculation today is just find the click point and find the point halfway between that and the bottom left to give you the new bottom left.
The problem is that this is unique. So what we need to find is the right bottom left that is nearest to the new bottom left.
Now one way to do this would be to do a 301 redirect for all requests to the "right" position. This is a perfectly valid way of getting people to use the right resource and of limiting the total space of the resource set. What you are saying in effect is that a request for resource X is in fact a request for resource Y and you should look at the new place to get it. This works fine in this scenario but for one minor problem.
The challenge we have is page views and a 301 redirect counts as a page view, meaning that we'd be doubling the number of page views required to get to a given resource. Valid though this strategy is therefore it isn't the one that is going to work for this cloud application. We need something that will minimise the page views.
But as this is a test.... lets do it anyway!
Technorati Tags: SOA, Service Architecture
2 comments:
301 is a permanent redirect, and hence well-behaving clients won't be coming back to that URI. So, it won't double page counts.
It will double the original number of page counts, and given that there are several thousand zoom permutations its really not very efficient at all as future requests are liable for a different resource and will get a different redirect.
So while, in theory if clients are well behaved, an individual redirect will be cached this doesn't actually improve the situation here very much.
Post a Comment