Nice post about how the various strands we’ve created in our digital life might be rewoven into a personal web space.
To put this another way, a distributed data storage system would take the place of a local storage system. And not just data storage, but data processing/filtering/formatting. Taking the weblog example to the extreme, you could use TypePad to write a weblog entry; Flickr to store your photos; store some mp3s (for an mp3 blog) on your ISP-hosted shell account; your events calendar on Upcoming; use iCal to update your personal calendar (which is then stored on your .Mac account); use GMail for email; use TypeKey or Flickr’s authentication system to handle identity; outsource your storage/backups to Google or Akamai; you let Feedburner “listen” for new content from all those sources, transform/aggregate/filter it all, and publish it to your Web space; and you manage all this on the Web at each individual Web site or with a Watson-ish desktop client.
Think of it like Unix…small pieces loosely joined. Each specific service handles what it’s good at.
Very Web 2.0.
For those who might be interested in seeing what a next-gen “Web Platform” looks like, take a look at this blog entry: http://about.picturem.com/default?archive=true&select=BlogSpace%2Fdefault%2Fzbox-snap.jpg
Last year at JavaOne, we introduced a new Web application server platform that was NOT based on the J2EE spec, but leveraged J2EE. The basic idea was to provide complete Web system so that developers have complete end-to-end control of all aspects of the Web, including a content mgt system, ful ACL security, object persistence, clustering, dynamic imaging services, transactions, and a real-time graphical development/deployment remote client. And of course it fell in deaf ears.
The picture in blog entry (which was developed and being run by a Zanvas server) is ZUI (Zoomable UI: O’Reilly ETC ’02) Java app that’s connected to the runtime server. I can zoom into the “home-page” content and edit it directly, so that the app server now runs off the newly modified content, which in short bypasses the need to fetch (e.g. HTML), open, edit, upload, and restart/re-init the Web (app) server so that it picks up the new Web content. Having an app server be also the content mgt. server makes this possible.
As a point of reference, it took 6 man months to build http://PictureM.com with two developers.
Some words from Marc Canter:
“Let me say this upfront. What Jason is spelling out has several problems – which he also perfectly elucidates.
What he doesn’t say is “that for all this to happen” – you need a COORDINATING company to make sure it all works. That’s obvious.
I’ll put my own answers to Jason’s issues – IN BOLD AND CAPS – but I think you’ll all see that Jason PERFECTLY spells out a realistic DLA scenario – thats’ totally open and doable – by year’s end.
Here we go.”
http://marc.blogs.it/archives/2004/08/kottke_explains.html