W3C home > Mailing lists > Public > www-tag@w3.org > January 2012

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

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Thu, 26 Jan 2012 06:02:26 -0800
Message-ID: <4F215CF2.8000507@oracle.com>
To: www-tag@w3.org
Hi Robin:
We seem to agree on two related directions for future work:
- How should applications be designed to work seamlessly in connected or offline mode.
- How should client-side data be synchronized with web data.
If you are available, we can discuss on today's call.
All the best, Ashok

On 1/26/2012 2:20 AM, Robin Berjon wrote:
> Hi Ashok,
>
> On Jan 25, 2012, at 14:46 , ashok malhotra wrote:
>> On 1/25/2012 2:47 AM, Robin Berjon wrote:
>>>  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.)
> Understood. I would tend to think that that's okay since the items in the IndexedDB might not be ones that are usefully exposed to anything beyond the code that was written to manipulate them. For instance the DB might contain log entries but may wish to only have URIs identifying monthly reports that aggregate these logs. Having IDB identify everything with a URI only to have it then hide most of that does not seem useful. It's entirely possible that I may be missing something, but I would tend to think that so long as people can use URIs to their hearts' content with IDB, it 's okay, no?
>
>> 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.
> Yes. This is going to increasingly become a requirement for many applications, and I suspect that there will be some pain points along the way that might be worth investigating.
>
>>>  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.
> Additionally, if you can synch from multiple devices or if the content of your DB can be influenced by other parties, the synch may need to be bidirectional.
>
> Things that could perhaps be usefully surfaced here include:
>
>  Are there existing protocols that could be used or adapted for this?
>
>  Are there specific things that one should be aware of when designing an application (server and client side) or an IDB data model that can help or hurt synchronisation?
>
>  Are there aspects of IndexedDB that could be improved or modified in order to better support synchronisation?
>
> Mind you, I may simply be worried about this because I'm largely a database ignoramus :)
>
Received on Thursday, 26 January 2012 14:02:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:44 GMT