[dojo-contributors] Dojo 1.9 Proposal

Kris Zyp kzyp at dojotoolkit.org
Fri Oct 19 09:38:53 EDT 2012


If it is of any use, here is some code I had started working to 
implement a dojo store using local storage (to eventually use IndexedDB, 
SQL, or LocalStorage, depending on availability). I haven't had time to 
work on it and finish it, so it is far from being anywhere close to 
complete, and I am certainly not suggested that we use it, or replace 
your code with it, but just thought I would post it in case there are 
any ideas in there that are worthwhile:
https://github.com/kriszyp/localdb
Thanks,
Kris


On 10/18/2012 11:58 PM, Kitson Kelly wrote:
>
>
> On 19 October 2012 01:11, Kenneth G. Franqueiro <kgf at dojotoolkit.org 
> <mailto:kgf at dojotoolkit.org>> wrote:
>
>     So I've started digging through your implementation.  While I may not
>     have grokked it 100%, I already have concerns/questions.
>
>     My biggest concern is that this is doing exactly what I feared when I
>     repeatedly discouraged "tightly coupling" - namely, it's
>     reading/writing
>     localStorage on every individual get/put/etc.  The query method
>     looks to
>     be excruciatingly inefficient, since it appears to be firing as many
>     separate get requests to localStorage as there are items in the store.
>
>
> I think I might not be making myself clear enough again.  My 
> expectation is that the Sync() object would handle that.  What is 
> bouncing around my mind is that this would be configurable in several 
> ways, but essentially would be a transaction queue, which would have a 
> default set of rules around how the ACID commands are handled.  By 
> default it may require a "flush".
>
> The goal of the WebStorage in my mind was to just have a dojo/store 
> API compliant store, and then build from there.
>
>     If the main purpose of this project is to sync to and from web storage
>     when necessary to facilitate offline use, then ideally there should be
>     no need to sync at every single operation, nor read from localStorage
>     for every single get/query.
>
>
> The main purpose is not to build an application, but a set of tools 
> which people can use to build an application.  Obviously I think the 
> main use case is for synching across in memory, persistent local and 
> sever side stores, but that may or may not be the only appropriate use 
> case.
>
>     Moreover, you seem to be largely reinventing the wheel that
>     dojo/store/Memory already implements.  Why not just extend it?
>
>
> Because in my mind dojo/store API was about exposing things in a 
> consistent API.  I expect the "extension features" to come from 
> combining data stores via the Sync() object.  I understand where your 
> thinking is, in as far as "it should be a memory store that is 
> flushable to persistent local storage", but I guess in my mind I am 
> taking a more composition approach which can provide a level
>
>     I also notice you replaced the simple random number generation for new
>     items with unspecified IDs with a UUID implementation.  I'm ambivalent
>     on this point at the moment since I'm not sure how relevant it is to
>     what we're actually trying to solve.
>
>
> Agreed, but Math.random() "worried" me, because it is far from a 
> compliant UUID.  It doesn't have to stay, but in my opinion, if we are 
> going to generate something, it should be compliant.
>
>     Anyway, let me know if I have the wrong idea about anything,
>     implementation- or intent-wise.  If you want, I'll try to throw
>     something together to illustrate my idea anyway, though there likely
>     wouldn't be a whole lot more to it than what I said above.
>
>
> I think I understand you thinking.  Let me get to the point where I 
> can demonstrate the Sync() thing that is bouncing around my head. 
>  Then if that doesn't make sense, maybe something like 
> "dojo/store/Persistent" could work, which would simply persist in 
> Local Storage.  MDN has available on it an implementation of Web 
> Storage in cookies.  So even in theory Persistent could degrade all 
> the way down to any currently supported 1.X browser.
>
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121019/47a6dfc8/attachment.htm 


More information about the dojo-contributors mailing list