[dojo-contributors] Dojo 1.9 Proposal

Kenneth G. Franqueiro kgf at dojotoolkit.org
Wed Oct 17 09:05:39 EDT 2012

Okay, at least I see more of what you're going after here now.  I did
realize shortly after my reply RE IndexedDB that it sounded a tad silly
RE browser support, but I also wasn't sure whether this idea was
intending to step into the territory of using different storage
solutions in different browsers (which starts to sound like
Lawnchair[1], which I actually messed with writing a Dojo adapter for
back around Dojo 1.6 / Lawnchair 0.5; the APIs have changed since then).

RE the first bullet (binding widgets to data that may be stored
locally), the crux of the point I've been trying to make here is that
there shouldn't be a direct binding here, and maybe that's actually what
you've had in mind all along, but I've gotten different vibes from some
posts on this thread.

If anything, you should be priming a store with data from
localStorage/IndexedDB/etc. once, and writing updates to it as
infrequently as possible - when exactly to do so *is* perhaps a valid
question for us to try to answer, considering that from what I'm reading
so far, the online/offline events and navigator.onLine variable may not
be incredibly useful[2].

We should not be rushing to conflate "storage" with "stores" to the
point of joining them at the hip - frequent reads/writes of persistent
storage of any sort will be less performant, and given how easy it
already is for people to abuse stores, I'm concerned that doing this
will set people up for a world of hurt.

It'd be easy to write an extension to dojo/store/Memory with methods to
sync to/from localStorage (or perhaps others) if we really want to.
Heck, once that's done it would also be trivial to aspect execution onto
add/put/remove, not that I would recommend someone do that.  But clearly
this is only actually a small part of the overall intended equation.

[1] http://brian.io/lawnchair/
[2] http://remysharp.com/2011/04/19/broken-offline-support/ (admittedly
this article is somewhat old; I'm not sure if it is any less applicable now)


On 10/17/2012 8:13 AM, Dylan Schiemann wrote:
> In the past, this is exactly the type of problem Dojo would have sought
> out to solve. Let's look at something like gfx. At the time, our choices
> were partial SVG support in Firefox, VML support in IE, and Canvas in
> Safari. We started by adding support for SVG and VML, and we attempted
> to do so in a way that would provide an API that would not encourage
> terrible behavior (we cannot prevent someone from exceeding the limits
> of what's possible in a browser, but if we wanted to do better, even
> today, we should publish some performance tests that show the limits of
> the API in various browsers). We later iterated and added canvas and
> silverlight support). For 2.0, it's likely that we'll drop all but SVG
> and Canvas, and add WebGL. We do this because people want a graphics
> API, we want an API we can build on top of for features like charts,
> drawing, and gauges.
> For local storage, the problem that I would like to see a simple
> solution for can be stated as follows:
> * How do I bind widgets to data that may be stored locally, as simply as
> I might use an object store?
> * How do I manage the issues of syncing data between something stored
> locally, and my server, when I switch between online and offline modes?
> Yes, there are plenty of problems and issues with storing and
> synchronizing data locally, but that's where a toolkit can add value,
> and also provide guidance on the limits and constraints under which such
> an API should be used.
> If we believe that we should only support APIs that work flawlessly
> everywhere, and then for such APIs, we don't need to provide a solution
> because the browser already solves the problem, then what is the purpose
> of a toolkit?
> Regards,
> -Dylan
> on 10/16/12 9:05 PM (GMT-07:00) Kenneth G. Franqueiro said the following:
>> RE IndexedDB, given the general lack of browser support (and, from what
>> I'm reading, difference in implementations), I'm not sure if that's a
>> road we'd want to go down either.
>> https://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-local-storage/
>> (first post linked in the footnote of the post I linked earlier)
>> explains some of the drawbacks to IndexedDB under the "Alternatives"
>> heading.
>> While clearly IndexedDB seems like something that a library like Dojo
>> would be far more justified in normalizing than something like
>> localStorage that pretty much solves itself, I'm not sure whether we'd
>> want to bank on something that won't work in IE9, Safari, Opera, and
>> iOS/Android (which apparently still favor the long-deprecated
>> WebSQL...something I doubt we'd really want to support).  On top of
>> that, IndexedDB seems like it would incur even more overhead than
>> localStorage.
>> Meanwhile, FWIW, apparently even localStorage might have some problems
>> on iOS: https://issues.apache.org/jira/browse/CB-330
>> --Ken
>> On 10/16/2012 7:27 PM, Ben Hockey wrote:
>>> 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 <mailto: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>
>>>>     > <mailto: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
>>>>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>>>>     > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>     _______________________________________________
>>>>     dojo-contributors mailing list
>>>>     dojo-contributors at mail.dojotoolkit.org
>>>>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>>>>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>> _______________________________________________
>>>> dojo-contributors mailing list
>>>> dojo-contributors at mail.dojotoolkit.org
>>>> <mailto: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
> _______________________________________________
> 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