Stateless Server Idea

| tags: blind, web, ideas, enabling technology, motor impaired, autism

I'd like to make a web application that will enable teachers to create simple "books" with hot spots on each page. The hot spots might play a sound or do some other action like changing to another page. Really simple stuff.

I can do a simple drag and drop interface for teachers to create books and provide a variety of access methods to accommodate kids with a different disabilities.

To make it more interesting I'd like to make this web service stateless. Hosting Tar Heel Reader has been great but administering a site with tons of user data is no fun. I don't want to store any of the media they use in their books on our servers. I can do that, I'm pretty sure, with Dropbox. But if I'm going to not store their media why store anything?

Experiments have convinced me that I should be able to store their book in the appcache in a modern browser. Appcache is the html5 machinery designed to enable offline operation. It looks like after they import the content into their appcache they shouldn't ever need to access our server again. This will be great for teachers who don't have wireless access in their schools; they just load up the "app" and go. By bookmarking the URL on their "home screen" on mobile devices, it should work pretty much like a conventional app.

They shouldn't need to access our server again unless... they want share their creation with someone else, or back it up; for that they need some representation that they can easily export and import. It's only a small text file (json format) describing the URL, positioning and response of the various media.

On desktop browsers I can just trigger a download dialog from my client-side javascript and have them save the json file. Later they can post that file to my server to recreate the book or load it onto another machine.

But what about tablets and phones? Especially iOS devices. How can they save and share their creation?

Approaches I've considered:

  • Encode it in the URL. This is nearly perfect; There are no additional steps to take when you clear your appcache or share the URL. Simply visiting the URL will recreate the content along with the manifest to get it loaded into your appache. But... the maximum practical URL length appears to be something under 8k bytes; even with compression that limits us to about 10 pages with 4 targets per page.
  • Use a mailto: link to package it into an email. Yuck, and I would have to worry about all the strange things mail systems do to message bodies.
  • Store it in the user's Dropbox. There is a javascript Dropbox API but to get write permission you have to apply for approval. Their page says they are only approving native mobile apps from trusted developers.
  • Encode it with stenography in an image. iOS lets you save and upload images though I bet Apple munges them somehow in the process.
  • Present them with the text and let them save it. They could share that text with others who would visit the editor page and paste it in. Ugly and prone to error.
  • Save it somewhere like Gist or Pastebin? Is there a place that allows anonymous web pages to write some text and retrieve it by URL? URL shorteners come to mind but then you're back to the URL limit. I say anonymous only because I don't want them to have to signup and auth for yet another service.
  • Is there some way to link to the Dropbox iOS app using a custom url protocol?

Does anyone have suggestions for how my iOS users could easily save and share this data? You'll have to email me, my comments were 99% spam so I turned them off.

Update: With the Dropbox App for iOS installed, Safari will offer Save to Dropbox for certain mimetypes. Unfortunately application/octet-stream isn't one of them. Anyway, I think I can stringify my object to json then construct a data url with some random mimetype and force a save dialog. Not nearly as pretty as having it all in the URL but it seems like a potential work around.