Offline support

[Henry Tappen]

Hi everyone,
I'm a big fan of Parchment and would love to contribute. Any objections if I give you a pull request for offline support? I'm thinking:

• Storing save games and cached stories in local storage (right now I have save games in DOMStorage to allow synchronous reads/writes and cached games in IndexedDB to allow lots of space)
• Listing the games that the user has cached on the home page

While we're at it, have you considered listing iplayif on the Chrome Web Store?

[Dannii Willis]

Sure, please do make a pull request! I have had plans to do this myself, but I don't have nearly enough time to do it all. I was planning to have a very simple DOMStorage system which stores one game file and a few save files for browsers which don't support IndexedDB. For those which do, everything can be stored there. And yes, the user's library should be shown on the front page too!

[Henry Tappen]

I have the approach you mentioned coded in my fork: https://github.com/htappen/parchment). The problem is that DOMStorage is highly limited on browsers other than IE. Safari gives you 1mb, Chrome 2.5mb, etc., which means that many larger titles can't even be stored (Zork, for example, is a couple megabytes and so doesn't make it. Anchorhead barely squeezes through on Chrome), and will probably be crowded out pretty quickly by save games. I think IndexedDB is the way to go.

[Atul Varma]

I agree that indexedDB is way better than localStorage, but another advantage of localStorage is that it works on IE8, which places with enterprise deployments (like libraries and workplaces) still use.

Since I suspect you just need key-value storage, perhaps it might be useful to use a simple abstraction layer that delegates to indexedDB if it's available, and falls-back to localStorage if not?

One abstraction I've run into lately is called Abstract LevelDOWN, which has both localStorage and indexedDB-based implementations:

  https://github.com/maxogden/level.js
  https://github.com/No9/node-leveldown-gap

Anyways, I don't mean to bikeshed or delay things--an IndexedDB-only solution is still way better than nothing! Thanks for the contribution.

- Atul

--
--
You received this message because you're subscribed to the Parchment Google Group. http://groups.google.com/group/parchment
 
---
You received this message because you are subscribed to the Google Groups "Parchment" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parchment+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
atul varma ⋅ toolness.com ⋅ @toolness

[Henry Tappen]

For what we're storing a full abstraction layer is probably a bit too heavy handed. We only need to store a story blob, a title, and a key. How about this hybrid approach: use localStorage for all save games, use IndexedDB to store story files if it's available, and fall back to localStorage if it's not (only allowing one cached story, and never clearing save files to make room for the story).

[Simon Booth]

I've already done a load of what you say

I've messed around with the entry and closures and added events to the code (it worked very nicely)

Additionally I've downloaded everything I can find and automated a build system for the entire z+b libraries (the binary ones)

Its a simple process

We currently have Scott's Adventure on free download for BB10

I wish I could get his other stuff to play nice as the license is nice enough to allow free copies

I'm pretty ingrained in the BB world

Simon Booth

A flawed genius (a quote about me)

[Henry Tappen]

Ok, if anyone wants to take a look, I have the changes more or less done in my GitHub fork: https://github.com/htappen/parchment

 

The changes are in

• library.js
• ui.js
• index.html
• parchment.manifest

There are a lot of commits since I was jumping between two different computers a lot while writing this. The next step on this is to test it on older browsers (it works on the latest IE, Chrome and Firefox)