You know when you can get a sense of what is coming, like feeling a small gust of wind on your face and sensing rain? I've got that right now about the real-time web. The idea that we're moving to a instant web, with data updating in real-time as apposed to delayed. You see it creeping forward everywhere - from facebook chat being built in erlang, to XMPP books proliferating.
This moves places huge strains on resources; both technical and strategically. How do you manage customer support digitally in real-time? How can we adapt our current web development stacks and methodologies to work with real-time data? Yet the deepest question is how 'real' do we need our real-time? Are seconds, minutes allowable? If so we can just be happy with pretty damn quick, rather than real-time. We can also to an extent fake real-time; we can use in-page notifications and other front-end tricks to illustrate the impression of real-time but actually make use of messaging systems and technologies such as comet and ajax polling calls to really do the work.
The recent open sourcing of the Tornado web server by facebook is an interesting piece of engineering; a non-blocking wsgi compliant web server de
signed to power friendfeed, an activity stream aggregator.
How do we prepare or build in such technologies into a normative digital strategy? I don't think there is a comprehensive view on where and when you can deploy such ideas apart from the generic where it makes sense and helps someone. Being able to get updates on a parcel tracking for example, would be a good idea, tell me when it's left a warehouse and let me know when I can pick it up or a van is five minutes from the delivery point.
I'm going to be writing more about what I call digital strategy as it's an area that really interests me. In future posts I'll try and talk about different options for achieving online results, without trying to sound too Nathan Barley.
