« Gravity and the Interest Graph | Main | Time to start … again. »

In Situ and in Sync

A small group of irregulars have been meeting on an ad hoc basis over the course of the past few months to consider mobile use of and influence on cloud-based (or, better said, network resident) services. From this group, Duncan Davidson of Bullpen Capital and Peter Christy of Internet Research Group have had a short conversation that was kicked off by a recent series of posts by Fred Wilson, venture capitalist and blogger, about the nature of content in use by mobile and less peripetetic devices.  The post in question, In Situ Content, prompted Peter to question "…whether remote acces to data and tools in the Cloud will ever be good enough."  He went on to support the idea of thick (or thicker) clients, and pointed to the recent Microsof Build Conference and which they showed off Windows 8 with Azure integration.

My thoughts in response.

I agree that for much of what wants to be done on a laptop/desktop, or on a tablet or smart phone for that matter, there is something 'thicker' than a dumb web browser required as the client.  

As the browsers acquire more heft, with both proprietary and more HTML5 based functionality, the browser becomes (at the very least) the fundament of any 'local client' technology.  Without this, the 'cloud applications' and the cloud storage of my data, my documents and collections will hit a wall.

In thinking about cloud storage of my personal possessions, I'd rather not think of things as 'documents'.  Rather, if one considers the active principle one of assembling and then 'rendering' a herd of data components (core data, meta-data, …) , we should use the term assemblage to replace the concept of document.  The assembly doesn't require physical proximity of data components, just a good and smoothly working linkage amongst them. 

I agree that, to the degree possible, the world will move toward the 'master data assemblage' (or what Duncan referred to as the ur-document) that resides in a cloud, and is sync'd for those situations where there is intermittent communication … which pretty much describes my iPhone and its use of AT&T Mobile's data plan.

The point is that it depends on accomplishing 'synchronization' well and correctly.  'Correctly', by the way, needs to cover issues of usability & user experience , safety (privacy & security), and economy (optimal utilization of compute, network and storage).  There is no single definition of 'correct' in these scenarios … the optimal recipe is going to completely depend on the context and the ability to adapt as the context changes for the mobile user.


PrintView Printer Friendly Version

EmailEmail Article to Friend

References (2)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (1)

Great post, Rich. Two (plus or minus one) comments:
- We will continue to oscillate between "thick" and "thin" clients as users and applications trade immediacy and "local" processing vs. simplicity and network-resident processing. I saw this occur with SSL vs. IPSec VPNs. This is fine, as it reflects the search for a "dominant design" in given application segments.
- I like the concept of "assemblage" ("melange"?) vs. "document" as it better captures the combination of different content and media types. Documents (as most people construct them) are static, even though they could be more dynamic. "Document" is perceived to be too much like "file", which becomes problematic when considering synchronization.
- "Synch" right now too often means "replicate"; it's a file-oriented thought. Take this collection of files and replicate them on a given set of media. As such, it's almost completely devalued (who's making money doing synch only these days?), except with regards to de-duplication and other storage-oriented value added services. Synch that was content-aware or otherwise intelligent might understand the relationship between objects in an assemblage, synch those objects to the medium most suited, and re-assemble those objects to recreate the assemblage when required.


Sep 28, 2011 at 2:16PM | Unregistered CommenterDan Callahan

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.