[dojo-contributors] Dojo 1.9 Proposal
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:
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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors