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

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?

• 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.

• 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.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 25 January 2012 10:47:42 UTC