Re: ACTION-647: Prepare product page for work on Client-Side Storage

Hi Robin, see inline ...
All the best, Ashok

On 1/25/2012 2:47 AM, Robin Berjon wrote:
> Hi Noah,
>
> On Jan 25, 2012, at 03:34 , Noah Mendelsohn wrote:
>> I've done just a little cleanup on a product page [1,2], setting out proposed goals, deliverables and schedules for TAG for on client-side Web application storage mechanisms.
>>
>> I will add this to the end of the agenda for the Thursday telcon, but if I receive any objections to discussing it so soon, I'll move it to the following week. Thank you Ashok for leading the effort on this.
> I have no objection, but a few notes:
>
> • I'm not entirely sure how to read "Should URIs be used for identifying locally stored data (...)". If we assume that I have an online database for my Little Pony collection in which an individual Little Pony may be identified as "http://berjon.com/lpdb/princess-celestia". That DB may be part of an application that can work both online and offline, and therefore uses both local and remote storage depending on availability. I think that what we want to get at is the fact that "http://berjon.com/lpdb/princess-celestia" should remain the same URI irrespective of which of those two stores is being used, but the way I read that paragraph I get the impression that it's saying that one should use localStorage["http://berjon.com/lpdb/princess-celestia"] = {...} to store that data on the client, and the same identifier to store it on the server side. Which one is intended?
Narrowly, this point came from the observation that IndexDB items do not have URIs (although URIs could be easily constructed for them.)
But, I think, you are touching on a more important issue:  how can we create applications that can seamlessly run in connected or offline mode.  For example, an application declares its dependencies; if it is running connected then it gets those resources from the Web.  If it is disconnected, it looks for those resources in AppCache or IndexDB or whatever.
> • A problem that's not mentioned is that of synchronisation of stores when you're using both local and remote DBs. I'm not at all an expert on the question, but I wonder if there are specific pitfalls and best practices that can be discovered in that area.
If we follow the seamless online/offline requirement, then you need to be able to update the local store and, at some point synchronize it over the Web.  The synchronization needs to be transactional.
> • Another issue with local storage is that of lock-in. If you have an application that uses local storage exclusively, given the current state of play users will be effectively locked into their browser if they don't want to lose their data.
So let's look at another requirement: the ability to store personal preferences (travel preferences or medical records) in local storage for access by applications.  Clearly, I need to be able to move my preferences from my laptop to my phone, and so on.  And, yes, the storage should be browser independent.

Received on Wednesday, 25 January 2012 13:46:20 UTC