A sketch: personal APP servers and feed-based web apps

OK, so I can’t remain a Luddite for long. What’s a technological solution to the posterity problem, in particular in regard to web applications that tuck away all your data in their databases, just waiting to be forgotten?

Well, what if web applications accepted information as feeds rather than through forms? The original data would be distributed rather than centralised. Web applications would use the web as more than a distribution medium: they would be of the web rather than simply on the web.

How it would work:

  • Keep your data on your computer (in XML where possible). Use whatever tool you like to create and edit it (by hand, using a dedicated standalone application, using a browser-based application in the manner of TiddlyWiki, or however), in some common markup language.

  • Serve your data through a web server that supports APP, and provide a feed that exposes the data. I’m not saying that this is easy for Joe Bloggs to do now, but if we’re talking about having web servers on mobile phones then surely it’s not long before having a personal web server is a matter of course, and why not with APP support? Feeds could be generated based on directory structures, or simply created as the main file format for a particular application.

  • Visit the web application that you want to use and point them at your data feed. They access, store and index your data, and relate it to the other data that they have stored from other people’s feeds. It’s their responsibility to keep their database up to date by doing a regular crawl of the feeds they know about; they don’t have to store all your data, just the bits that enable them to do their job.

  • Edit your data through the web application’s interface; it can update your data for you using APP. (The web application is a APP client, and you host an APP server.) That can include adding comments or whatever other community-level annotations you might expect.

Why bother?

  1. You have all your data locally (although it might be mirrored elsewhere).
  2. You can edit your data in whatever tool you want to use, but still use a funky “rich internet application” to view it and share it.
  3. You can provide the same data feed to any number of web applications; you’re not locked in.
  4. Because it’s stored locally, your data is available for viewing and editing even when you’re offline.
  5. Because the important parts are cached by a web application, your data is available for viewing and editing even when you’re away from your normal computer.
  6. Your friends can access your data directly in a peer-to-peer network.

The obvious problems:

  • Setup: Web servers aren’t that easy to set up and maintain at the moment, because they’re designed for the use of sysadmins who are quite happy hacking text-based configuration files. That could change (look at WiFi router setup nowadays compared to how it was a few years ago).

  • Security: you might not want everyone to be able to access the data you keep on your personal web server. So you’ll need a way of assigning user names and passwords to feeds, and only handing those over to web applications that you trust.

  • Server load: it’s not so much DoS attacks (which tend to have big juicy targets), but the fact you’re more likely to experience large volumes of requests if, say, a picture you host suddenly gets popular, and might not be able to respond to them, or might have to start paying heavily for the bandwidth. So sites that offer hosting will still be really useful, particularly for media that’s (a) large and (b) likely to be embedded in other people’s pages.

  • Schemas: you can’t split creation of XML from processing of XML unless you have some kind of mutual understanding about the markup language that’s used. This used to seem like a major stumbling block to me, but in fact people seem to be sensible enough to use standards where there are standards, write stylesheets to convert between languages, extend what exists with what they need in more-or-less acceptable ways and generally muddle through without spending years in meetings thrashing out a single consensual model. And Atom and APP are pretty good at supporting extensions and so on that would make that work.

My hope is that we’ll get round to trying some of these ideas out in our genealogy-based Web 2.0 project.

Comments

Re: A sketch: personal APP servers and feed-based web apps

Hi Jeni,

So strange that you have been blogging about these various subject matters (the XSLT-based MVC framework, APP-based personal publishing system) while at the same time I’ve been building each and every one of these things. http://nuxleus.com is a Linux-based virtual appliance that facilitates an entire personal publishing system built on top of Mono and Saxon on .NET. The core of the platform ( http://nuxleus.googlecode.com/svn/trunk/nuxleus/src ) will run as a ClickOnce application or standalone on Windows, Mac, or Unix, so a virtualized appliance isn’t necessary, just a bit more contained and a bit more powerful (e.g. a full suite of development tools is included on the nuXleus distro as is a complete virus protection system)

My lastest post to XML.com @ http://www.oreillynet.com/xml/blog/2007/10/blipmessaginghitsthestreet.html highlights one of the ways we are using the platform. I REALLY love the idea of creating a decentralized Genealogy-based Web 2.0 project. I wonder how I might be able to help?

Re: A sketch: personal APP servers and feed-based web apps

“while at the same time I’ve been building”

Correction: While I am my co-workers (Russ Miles, Sylvain Hellegouarch, Eric Larson, and Jacob Joaquin on the software development side of the business) have been building… I started it. We’ve been working together to finish it.

Re: A sketch: personal APP servers and feed-based web apps

“I am my coworkers”? Dear God, I need to learn how to type!

While I AND my co-workers.

Re: A sketch: personal APP servers and feed-based web apps

Forgot to mention that the core Nuxleus platform is built 100% on top of APP and Atom. One example of how we’ve been using it is to use Atom feeds as well to describe the components necessary to generate a web application. People then subscribe to that applications web feed and generate that application locally, updating the components when the feed has been updated.

Re: A sketch: personal APP servers and feed-based web apps

  1. Use a plain text editor.
  2. Ensure a couple of lines are parsable (create a blank using languages X, then fill in metadata)
  3. Save.
  4. rsync/svn/whatever to commit to a server (svn works for me. Windows or Linux)
  5. Pull the data (svn update) from whichever machine you’re on.

Only need to go to XML/binary if needed for some other reason?

DaveP

Re: A sketch: personal APP servers and feed-based web apps

@DaveP,

We’ve been playing around with some code[1,2,3] that uses a filesystem watcher to capture events fired off (e.g. new file/folder is added, file/folder is deleted, file/folder has changed) when something on the folder being watched has changed and handles the events by adding, deleting, or committing changes made to a file/folder to either SVN or Darcs. The problem thus far is that we haven’t been able to really properly map all the events that transpire to the proper operation in either SVN or Darcs so have instead resorted to using our built in APP system (which we’re in the process of re-writing in C# and XSLT 2.0) to add a new Atom feed to the system when a new file is created, mark that entry as deleted when deleted, and add a new entry to a files Atom feed that contains the diff (using Joshua Tauberer’s Diff util[4]) based on the original entry as a new entry.

There’s still a bit more work to do, but the end goal is that of creating an ad hoc decentralized AtomPub collections-based revision control system that uses nothing but the feeds URI and its entry ID to rebuild the state of any given “repository” with nothing but good “ol’ fashioned” HTTP(s) and URI’s as its heart and soul.

To me, anyway, it feels like the right approach. Thoughts?

[1] http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.IO/FileSystem/Watcher.cs [2] http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Process/Process/SVNProcess.cs [3] http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Process/Process/DarcsProcess.cs [4] http://razor.occams.info/code/diff/