[dojo-contributors] Dojo 1.9 Proposal

Kitson Kelly me at kitsonkelly.com
Fri Oct 19 01:58:53 EDT 2012

On 19 October 2012 01:11, Kenneth G. Franqueiro <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121019/11809309/attachment.htm 

More information about the dojo-contributors mailing list