[dojo-contributors] Dojo 1.9 Proposal

Ken Benjamin kenbenjamin at kenbenjamin.net
Fri Oct 19 02:06:50 EDT 2012


Ben and All,



Chrome, according to the link you posted, now supports up to 10% of
available disk space per app. (20% of 50%, if you read over the article). I
just checked that using the following function:



webkitStorageInfo.queryUsageAndQuota( webkitStorageInfo.TEMPORARY, /*or
.PERSISTENT*/ function(use, avail){console.log('Using',
Math.round(use/1024), 'out of', Math.round(avail/1024), 'Kb (',
Math.round(use/avail*100), '% )');});



Safari 5.1 seems to default to 5Mb but offers user-controllable amounts up
to 500Mb. Here’s how it describes the process in help (emphasis added):

Database storage

Websites that provide tools for you to create and edit documents sometimes
store your documents as databases on your computer. You can increase or
decrease the amount of space available for this purpose. **If a website
requires additional space, a message will appear on your screen.**

I haven’t delved further into the details but it looks promising.



IE10 appears (it’s IE so who knows whether is works or not) to have support
for IndexedDb (and other standards). Very little detail is provided beyond
the API but here is the reference:
http://msdn.microsoft.com/en-us/library/windows/apps/br212883.aspx



One question I would have is, much as this would be a nice-to-have feature
in 1.9, wouldn’t it fit better in 2.0 where support for legacy browsers is
dropped? It seems to me that if we put this in the 1.x line that users
should have every right to expect it to work with the same suite of
browsers that other aspects of 1.9 support. My suggestion is that it be
made available as a separate project ala dGrid, and integrated into
dojo/store for 2.0.



Ken B



*From:* dojo-contributors-bounces at mail.dojotoolkit.org [mailto:
dojo-contributors-bounces at mail.dojotoolkit.org] *On Behalf Of *Ben Hockey
*Sent:* Wednesday, October 17, 2012 1:28 AM
*To:* dojo dev.
*Subject:* Re: [dojo-contributors] Dojo 1.9 Proposal



i'd agree that IndexedDB is a better target for this kind of thing but
unfortunately right now browser support for IndexedDB is limited to FF and
chrome with support coming soon in IE10 but so far nothing on the horizon
for mobile or safari (http://caniuse.com/#feat=indexeddb).  the size is
still quite restrictive in chrome (5MB -
https://developers.google.com/chrome/whitepapers/storage#temporary) but FF
has a better story (http://support.mozilla.org/en-US/questions/818987).



i'd say that it's a novel idea to use Web Storage but in my opinion the
real usefulness would be IndexedDB.  as tom said, the store API is based
around that same API.



ben...





On Oct 16, 2012, at 12:39 PM, Tom Trenka wrote:



I don't want to rain on anyone's parade, but honestly if we're thinking of
this as an offline thing it'd probably be much better to wrap the IndexedDB
than LocalStorage, at least based on my experience (which admittedly is
about 2 1/2 years old now and in the context of Adobe AIR).  I remember
running into the same problems Ken and Colin have alluded to; LocalStorage
tends to be very slow, especially with larger data chunks...and IIRC
there's a limit as to how much can be stored in it.  And given that most
people are using DTK to build single-page applications, that might end up
being a bad thing.



Kris deliberated designed the dojo/store API based on IndexedDB; perhaps if
we're looking for an integrated solution, that would be a better path of
investigation?



Tom

On Tue, Oct 16, 2012 at 11:08 AM, Kenneth G. Franqueiro <kgf at dojotoolkit.org>
wrote:

Further responses inline.


On 10/16/2012 11:52 AM, Kitson Kelly wrote:
> Comments inline...
>
> On 16 October 2012 16:10, Kenneth G. Franqueiro <kgf at dojotoolkit.org

> <mailto:kgf at dojotoolkit.org>> wrote:
>
>     As with the last time the idea of web storage + dojo/store was brought
>     up, I would raise concern at the idea of introducing this "feature".
 I
>     may not have the most informed of opinions on the matter, but the
>     following things stick out to me:
>
>     * Which way would we "solve" this?  One write per atomic store
>     operation, or have developers call a method to persist all items at
>     once?  (Based on your idea of using Cache, I'm guesing the former; I'm
>     inclined to expect that the latter may actually perform better - i.e.
>     write all data to one key at once.)
>
>
> The "why" to me is that we provide a Memory store with a consistent API
> interface, but if you want to use Web Storage, you have to learn another
> API.  None of the widgets and other objects which are "data aware" can
> leverage Web Storage, without some level of bespoke code.  I personally
> think this is making it difficult for creation of "offline" capable
> applications with Dojo/Dijit both in the desktop and mobile space.

It's not difficult to extend dojo/store/Memory with localStorage support
if you want it.  We do it (though perhaps not ideally, going back to the
points in my previous reply) in one of the simple dgrid demos.


>
> Of course an end developer could directly use the HTML5 Web Storage.  I
> maybe missing something, but if you needed to develop an application
> that persisted date between page loads without always having a
> connection to a server, outside of using cookies, how would you
> accomplish this with Dojo?
>

Let me pose an unrelated but equivalent question, in an attempt to
illustrate a point: how would you iterate the keys of an object with
Dojo?  The answer is, you wouldn't.  Dojo doesn't make a habit of
providing solutions for problems that are already solved.


>
>     * But moreover, who's to say we really have the right to prescribe one
>     or the other for every situation, when in reality it would take
someone
>     very few lines of code to implement either approach him/herself?
>
>
> Again, how would you connect a Dijit, dgrid, GridX and any other
> dojo/store API to Web Storage?

You would write a few lines of code to extend dojo/store/Memory in
whichever way you see fit to back it with localStorage.  Again, I think
it's disingenuous for us to make the decision as to "whichever way" for
devs.  It seems more like grounds for a tutorial (exploring multiple
solutions) than a feature.


>
>
>     * Performance implications (see perhaps
>
http://www.nczonline.net/blog/2012/04/25/the-performance-of-localstorage-revisited/
>     and in particular, the first link in the footnotes)
>
>
> A valid end-developer concern about which approach to take.  I don't
> think performance should preclude us from considering it though.  Also,
> as some of the comments have made, read into memory, work on data set,
> save back to storage.  Unless I am missing something though, I don't see
> a way to easily persist data between sessions to create offline capable
> applications any other way.

I just don't want to see us implement something that encourages or makes
it easy for people to shoot themselves in the foot.  My point of linking
that article wasn't so much about localStorage vs. something else, as it
was cautioning against leaning heavily on it (and perhaps in the wrong way).


>
>     * Now you're also raising the implication of affecting another API
>     (dojo/store/Cache) just for the sake of a single implementation, which
>     to me sounds suspect (let alone that the potential implementation in
>     question also sounds suspect to begin with).  I'm also not really
sure I
>     understand what kind of changes you have in mind.
>
>
> Possibly.  That is why it is a proposal and the benefits of discussing
> in the open. :-)
>
> If we affect the Cache API in a way that break compatibility, then
> obviously that is a non starter, but I would suspect people maybe
> re-inventing the wheel, in that I have a level of concern with
> dojo/store/Cache that it has no real logic of what data gets persisted
> where other than "avoid fetching the same data again".  It simply copies
> all fetched data to both stores and if it doesn't think it has changed
> retrieves it from the cached store.  Whenever anything is .put() it
> is immediately propagated to both stores.  While Cache might not be the
> right place to add it, there almost needs to be a mediation layer that
> can be used to track transactions and commit those to a remote store in
> a configurable fashion as well as synchronise between a local and remote
> store in a configurable way.  So I don't wholly see it as a
> single implementation argument.  I see it as a dojo/store compatible API
> for Web Storage and providing an intelligent mechanism to
> replicate/synchronise data between data stores.
>

This sounds like it's sorely overcomplicating the scenario as opposed to
what Cache currently solves.  It sounds to me like it should be a
separate entity, if it is to exist at all.


> If it ends up being a "bad idea" there is plenty of time between now and
> the release of 1.9 to agree to not do it, but if there is a "this might
> work" then I am willing to expend time and effort on it.
>
> Again, the main use case would be to allow the creation of offline
> capable applications that will function between page re-loads or across
> pages.
>
>
>

> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



_______________________________________________
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/ef96a485/attachment-0001.htm 


More information about the dojo-contributors mailing list