[dojo-contributors] Dojo 1.9 Proposal

Kenneth G. Franqueiro kgf at dojotoolkit.org
Thu Oct 18 20:11:12 EDT 2012


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.

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.

Moreover, you seem to be largely reinventing the wheel that
dojo/store/Memory already implements.  Why not just extend it?

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.

I was bouncing around some ideas last night and the first thing that
came to mind was to extend Memory, and simply add 2 methods - one to
persist to local storage, and one to restore from it.  These would most
likely operate on a single localStorage key containing all the data, not
one key per item.  It'd be trivial to aspect the persist method onto
add/put/remove (to auto-commit so to speak), but I wouldn't encourage
it, assuming we can find sufficient means to detect when to switch to
and from localStorage.

I didn't put anything together yet since I figured it'd only be a
ridiculously tiny part of the overall equation (and perhaps even an
oversimplification), but it seems like it'd be filling the same part of
the equation as this WebStorage store.

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.

--Ken

On 10/18/2012 12:54 PM, Kitson Kelly wrote:
> 
> On 18 October 2012 16:33, Kenneth G. Franqueiro <kgf at dojotoolkit.org
> <mailto:kgf at dojotoolkit.org>> wrote:
> 
>     I don't have time to look at this right now, but very quick points:
> 
>     * I don't think this belongs as part of dojo/store.  It seems like
>     something that should be in its own package (like dojox/storage was).
> 
>     I mean, heck, should I have just made dojo-smore on a dojo fork then
>     too?  It's primarily stores that people keep asking for. :P
> 
> 
> Obviously, it can be put anywhere when done, the beauty of AMD.  We said
> no new packages for DojoX in 1.9, so that is what led me to starting in
> the most logical place, for a POC.  Dylan was the one who suggested he
> wanted it in 1.9, I simply raised my hand to say I had the time and
> inclination.  If it ends up being a separate package, folded into smore,
> or whatever does not matter to me one iota.
>  
> 
>     * It's IndexedDB, not IndexDB.  Figured you might want to get that
>     ironed out before you potentially start naming things after it :)
> 
> 
> Yes, already caught that.  Again, the beauty of AMD it was an easy
> mistake to correct.
> 
> 
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


More information about the dojo-contributors mailing list