[dojo-contributors] Dojo 1.9 Proposal

Kitson Kelly me at kitsonkelly.com
Tue Oct 16 11:52:45 EDT 2012

Comments inline...

On 16 October 2012 16:10, Kenneth G. Franqueiro <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.

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?

> * 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?

> * 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.

* 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121016/9c14f114/attachment.htm 

More information about the dojo-contributors mailing list