The web is a giant distributed state machine. Sometimes, however, I think of the web in kind of a weird way, as just another program running on my pc. Following this simplistic thought process, I can use the web by entering a string, hitting Enter, and receiving back a page of data. In other words – it’s just a simple “function” that performs a task similar to that of a clerk at the post office. Of course, this way of looking at the web makes it seem trivial, but at the same time, you have to admit, it’s kind of accurate – because that’s the way the web actually looks from your desktop.
So, if the web is just a big “function”, then what’s so interesting about it? Well, one thing jumps to mind. Each time you issue a parameterized request, you have the ability to cause the state of the web function to change internally. For example, 6 months ago, I issued a request to the web that caused it to change its state, indicating that I now had 4 tickets on Delta airlines. Of course, I was buying plane tickets via the web, and I had just submitted the final form that contained the “OK” information to commit the transaction. But looking at this from a super simplistic point of view, I entered a string of characters into the web “function” and hit Enter. Back came a pile of data, and of course, the change in state that indicated that I now owned 4 tickets.
The reason I’m making the web out to look like a simple “function” is because it helps me think about things we could do to make this function more useful.
Enter the idea of the “delta web”. Think of the delta web as being a kind of “function” as well. The delta web’s function is to quantify state changes in the web function. What does this mean? Well, let’s set the stage as follows, and bear with me. Let’s call the web function F. F takes a parameter called URL, which we’ll call u, and it returns data called d. So, when I issue a request to the web, via my browser, what I’m really doing is issuing a call to F(u), and F(u) returns d, so we have d = F(u). That might not sound so good, but what the heck.
Next, because we said that the web has this interesting characteristic where the state can change over time through regular use, it means that the time parameter “t” has to somehow figure into the function F as well. In other words, F is not just a function of u, which would make F stateless. Since F(u) can be called, and return data d, and possibly change its state internally, and then since F(u) can be called again in the future and return a different d – namely d’, because the state changed, we have to add t to the function F. This is how we do it. The web function becomes: d = F(u, t). This way, d = F(u, t) can produce one result, whereas d’ = F(u, t + i) can produce a different result, simply by varying time. The t + i part just means that t is a different time from t + i.
So, the delta web ends up being a function that represents the first derivative of the web function with respect to one of the variable input parameters: u or t. Written in pseudo math terms, the delta web is essentially dF/dt or dF/du, where F(u, t) is the function representing the web. For now, I’m interested in the rate of change of the web with respect to the parameter time – and hence dF/dt.
OK – where’s all this going? Imagine a function that could track change to the web as a function of time, and put this to use in a positive way. This would be useful. Especially if you could look forward in time and examine units of change in the web, relative to units of change in time. This would be like looking at the elevation course map for a bike race and realizing that you’re about to come up onto a monster hill in two miles. Using this map, you could anticipate the change in course pitch, and prepare by taking a deep breath and concentrating.
Now, I’m going to really change gears and put this whole conversation into a business context. Let’s say that an airline has a flight booking service on the web that let’s people buy tickets online. Let’s say that in two weeks, the airline plans to cut the price of its flights from Boston to LA from $1200 to $200. The web function in this case is “find a flight”, and it is characterized by a unique URL that feeds the web function. In this case, the URL contains information defining the origination city, destination city, and departure date. The return of the function is a set of flight numbers, prices, and availability.
The delta web function for this case would be characterized as “changes to find a flight”. The delta web function is driven by the same kind of URL parameter, as in the “find a flight” web function above, in addition to a time parameter that defines the point in time in which you’d like to measure the change to the web function. This means that if you gave the delta web function a URL, along with a time t – past, present, or future, then the delta web function would tell you about changes to the web function at any of those points in time. Using the delta web function, a business that utilizes the web function could adjust the way it uses the web function for points in the future. For example, a syndication partner that provides embedded access to the “find a flight” service from its own site, might decide to change the way it handles the return data from the URL, so that it either passes on the price drop to the partner’s end users, or pad the price back up in order to keep a cut of the price drop for itself.
The delta web function could also be used to track the more simplistic kinds of changes to the web function that RSS is used to track changes to weblogs. The delta web function would have general purpose syntax for defining context of change, characteristic of change, and point of time of change. For example, if you added an entry to your weblog today, and wanted to update the delta web at the same time, you’d create a unit of data that combined the context of the change (i.e. the URL to the blog), the characteristic of the change to the blog (i.e. the relative URL to the new entry, and the type of operation - namely “add”), and the point in time of the change. With this new piece of data, you’d update the delta web so that one could issue a query to the delta web in the form of URL and date, and get back the change data describing the change relative to that URL and point in time.
Since the web function F is a giant function that lets you specify many billions of sub-functions in the form of URL’s, the delta web could simply be implemented as just a set of sub-functions within the giant, already existing function F. In other words, people could create their own delta web sites that would be hosted by the web. You don’t need a separate web for dF/dt that takes URL and time t. Instead, you could have web sites that would allow input parameters in the form of URL and time t, and they’d produce delta web formatted markup documents.
The next thing to consider is the markup for delta web data. A simple approach would be to create an XML schema for delta web data. This could then ride inside payloads such as SOAP, RSS, whatever.
Moving beyond the issue of syntax for delta web data, what’s really cool is imagining new kinds of software that would consume and produce delta web data. Let’s take the case of web based calendars. Say that I decide to post a set of URLs on the web, whereby each one returns an XML-based event schedule for a specific month. Let’s also say that I provide information that tracks changes to my scheduled events, by providing a delta web document that identifies changes at different points in time.
Given this delta web data, one could write an aggregator that would track changes to calendars, and use this “delta” information to either update someone else’s calendar, or produce a new “higher level” delta web document. Here’s where it gets interesting. An aggregator of the delta web would be able to do things like provide its own summarization delta web documents for other delta web aggregators. An example would be a delta web aggregator that would look at all the delta web docs for a set of employee calendars, update a group level calendar, and build a coarser grained delta web document representing changes to the group’s calendar. If all the employees became busy at various times next week, the group level delta web aggregator could update “blackout periods” on the group level calendar, and update the delta web doc for the group calendar.
Another freaky thing you could imagine is delta web docs that track changes to other delta web docs. These higher order delta web docs would be representative of “second derivatives” of the web function. You could also imagine delta webs that measure perturbations – or changes to the web function – as a function of the web’s URL parameter – rather than time. A delta web could measure the change in the web’s response function when a URL’s parameters were changed.
One of the next steps is to define a simple markup for the delta web. As I see it, there are 4 key elements that define a change: 1) the pattern that defines the context of the change, 2) the pattern that defines the boundary of the change relative to the context, 3) the nature of the change (add or delete), and 4) the point in time of the change. Following is a brief discourse on each.
1) Pattern defining context of change – this is a URL. It’s a pattern, used by the web function to define a precise sub function. In simple web terms, it could be a URL to an XML document.
2) Pattern that defines the boundary of the change – this is a relative URL. In the simple XML document case, it could be an XPath reference to an element in the XML document. The XPath ref defines the beginning and ending of the change – namely the start and end element marker locations.
3) The nature of the change – this is simple – add and remove. In the case of add, the meaning is that we added the data matching the pattern defined in 2) above. In the case of remove, it means that we removed the data matching the pattern defined in 2) above.
4) Point of time of the change – this is the date when the change takes place.
More to come soon!!!
Ps – I was a physics major in college – which might provide a bizarre explanation for the really whacko way I conceptualize the web.
5:06:21 PM 
|
|
